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Proceedings  of  the  CASE  Adoption  Workshop 

Abstract:  The  Software  Engineering  Institute  (SEI)  CASE  Technology  Project 
sponsored  a  workshop  to  address  a  number  of  key  CASE  adoption  issues.  The 
workshop  was  held  at  the  SEI  in  Pittsburgh,  Pennsylvania  on  November  13-14, 
1990.  At  the  workshop,  a  representative  group  of  SEI  affiliates  from  industry, 
government,  and  academia  discussed  among  themselves  such  adoption  topics 
as  CASE  benefits,  realistic  CASE  budget  estimates,  CASE  tool  fit,  CASE 
adoption  roles,  and  factors  in  the  project  success  of  CASE.  The  results  of  these 
discussions  are  summarized  in  this  report. 


1  Introduction 

The  adoption  of  new  technology  into  an  organization  is  rarely  a  simple  matter.  This  is  true 
when  adopting  a  new  CASE  (computer-aided  software  engineering)  technology  into  a  large 
organization.  There  are  many  factors  that  have  an  impact  on  the  ultimate  success  or  failure  of 
a  new  CASE  tool.  Potential  adopters  should  be  aware  of  these  factors,  so  they  can  consider 
what  ramifications  they  might  have  in  their  organization  and  plan  accordingly. 

A  CASE  adoption  workshop  was  held  at  the  'ftware  Engineering  Institute  on  November  1 3- 
14,  1990,  to  collect,  explore,  and  share  the  CASE  adoption  expertise  and  insight  of  the  SEI 
affiliates.  This  workshop  gathered  43  professionals  from  industry,  government,  and  academia 
with  a  common  interest  in  CASE  and  CASE  adoption.  It  was  sponsored  by  the  CASE  Tech¬ 
nology  Project  at  the  Software  Engineering  institute. 

1.1  Keynote  Address 

As  the  introductory  keynote  address,  Dr.  Jonathan  Morell  of  the  Industrial  Technology  Institute 
spoke  on  “CASE  Implementation:  Dynamics  Through  the  Technology  Life  Cycle.”  This  ad¬ 
dress  and  the  commentary  that  followed  were  based  on  the  considerable  experience  that  he 
and  the  Industrial  Technology  Institute  have  in  transitioning  many  forms  of  high  technology 
from  research  to  commercial  practice.  Summarized  below  are  his  four  keynote  conclusions: 

•  CASE  implementation  can  be  planned,  managed,  and  evaluated. 

•  Efforts  to  promote  the  use  of  CASE  must  be  seen  in  terms  of  the  entire 
technology  life  cycle. 

•  Strategies  within  that  life  cycle  have  varying  time  horizons  for  success  and 
different  requirements  for  collective  and  individual  action. 

•  Within  any  single  organization,  CASE  implementation  hinges  on  a  set  of 
highly  dependent  interactions  among  HiTOP  (High  Integration  of 
Technology,  Organization,  and  Peopled  elements. 

For  a  complete  hard  copy  of  his  companion  paper  on  this  topic,  see  Appendix  E. 
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1.2  Workshop  Session  Overviews 

There  were  five  concurrent  workshop  sessions: 

•  Adoption  Roles  and  the  Adoption  Life  Cycle  for  CASE  Tools. 

Identified  the  key  roles,  activities,  and  issues  that  must  be  addressed  in  a 
typical  adoption  life  cycle  for  CASE.  During  the  session  these  items  were 
documented  in  a  Life  Cycle  Matrix.  The  matrix  suggested  entry  and  exit 
criteria  and  actions  to  take  for  each  adoption  life-cycle  phase,  and  issues  to 
pay  attention  to  for  each  of  the  appropriate  roles  in  a  particular  adoption 
phase. 

•  Can  You  Get  the  Benefits  of  CASE  Without  Buying  It? 

Determined  which  benefits  (if  any)  could  be  derived  from  CASE  technology, 
independent  of  the  CASE  tools  themselves,  i.e.,  benefits  that  result  from  the 
formal  specification  of  a  development  project. 

•  The  ‘CASEability’  of  Projects. 

Examined  what  essential  qualities  of  a  software  development  project  must 
exist  to  introduce  CASE  or,  if  already  begun,  to  accelerate  CASE  adoption. 
In  addition,  the  session  tallied  a  list  of  recommended  actions  needed  to 
create  these  essential  project  qualities. 

•  Developing  a  Realistic  Estimate  for  CASE  Tool  Adoption. 

Developed  a  core  cost  estimation  framework  to  aid  others  in  preparing 
detailed  CASE  budgets.  This  CASE  budget  framework  included  guidelines 
for  determining  the  amounts  of  people,  time,  and  money  needed  for  CASE 
tool  adoption. 

•  Making  the  CASE  Tool  Fit  the  Organization  and  the  Organization  Fit  the 
CASE  Tool. 

Explored  tool  and  organizational  characteristics  that  facilitate  or  inhibit 
CASE  tool  adoption.  Examined  changes  to  tools  and  to  organizations  that 
improve  the  chances  for  successful  adoption. 
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2  Executive  Summary  of  CASE  Adoption  Workshop 


This  first  CASE  Workshop  sponsored  by  the  SEI  yielded  useful  models  and  insights  to  aid  SEI 
affiliates  in  their  efforts  to  integrate  CASE  technology  effectively  into  their  organizations.  In 
some  cases  the  sessions  had  implications  for  additional  work  and  future  research.  One  such 
topic  is  the  CASE  estimation  model,  which  aids  in  developing  realistic  CASE  estimates.  In  ad¬ 
dition,  the  session  on  the  CASEability  of  projects  raised  a  number  of  provocative  issues  for 
SEI  consideration.  Summary  results  from  each  of  five  CASE  Adoption  Workshop  sessions  are 
presented  below. 

2.1  Adoption  Roles  and  the  Adoption  Life  Cycle  for  CASE  Tools 

This  session  identified  the  key  roles,  activities,  and  issues  that  must  be  addressed  in  a  typical 
adoption  life  cycle  for  CASE.  These  items  were  documented  in  a  Life  Cycle  Matrix.  The  matrix 
illustrated  entry  and  exit  criteria  for  each  adoption  life-cycle  phase,  identified  specific  actions 
to  take,  and  illuminated  issues  for  each  of  the  appropriate  roles  in  a  particular  adoption  phase. 
This  matrix  provides  a  good  model  for  change  agents  to  use  when  planning  and  executing  a 
CASE  adoption  in  their  organizations. 

The  completed  matrix  is  composed  of  42  cells.  The  matrix  contains  6  columns  of  roles  and  7 
rows  of  life-cycle  phases.  The  5  roles  are: 

•  Upper  Management 

•  Line  Management 

•  Product  Champions 

•  Change  Agent 

•  Pilot  Project  Team 

•  Target  Users 

The  7  life-cycles  phases  are: 

•  Assess  the  Need 

•  Select  Candidate  Products 

•  Evaluate  Candidate  Products 

•  Present  Product  to  Management,  Users 

•  Gather  User  Information 

•  Plan  the  Implementation 

•  Implementation  and  Ongoing  Support 
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2.2  Can  You  Get  the  Benefits  of  CASE  Without  Buying  It? 

This  session  addressed  which  benefits  (if  any)  could  be  derived  from  CASE  technology,  inde¬ 
pendent  of  the  CASE  tools  themselves. 

In  general  terms,  CASE  technology  can  be  thought  of  as  “any  computer-based  assistance  that 
reduces  the  labor  intensity  of  project  development."  Participants  in  this  session  felt  that  the 
current  orientation  of  CASE  to  software  is  at  too  low  a  level,  and  that  what  is  really  needed  is 
Computer  Aided  Project  Engineering  (CAPE). 

Participants  determined  that  the  primary  benefit  of  CASE  tools  is  in  the  enabling  or  automating 
of  a  defined  methodology.  A  methodology  is  essentially  a  network  of  iterative  work  tasks.  To 
benefit  effectively  from  CASE  technology,  users  would  first  have  to  define  a  methodology  ap¬ 
propriate  to  their  development  process.  But  in  automating  a  methodology,  automation  should 
not  control  the  development  process  or  methodology,  but  rather  should  work  flexibly  in  support 
of  the  project. 

Finally,  as  the  emphasis  of  the  session  was  on  CASE  without  tool  support,  participants  dis¬ 
cussed  several  aspects  of  CASE  that  related  specifically  to  adoption  of  the  technology.  The 
following  conclusions  were  drawn: 

•  Many  methodology  decisions  give  inadequate  regard  to  cost. 

•  Management  underestimates  the  difficulty  of  change. 

•  Productivity  is  the  result  of  a  well-defined  process. 

•  Process  quality,  not  productivity,  must  be  the  focus  of  change. 

•  Product  quality  will  result  from  process  quality. 

•  Tools  will  evolve  in  support  of  a  viable  defined  methodology. 

2.3  The  ‘CASEability’  of  Projects 

This  session  examined  what  essential  attributes  of  a  software  development  project  must  exist 
to  introduce  CASE  or,  if  already  begun,  to  accelerate  CASE  adoption.  It  uncovered  no  “silver 
bullets,”  but  it  did  identify  a  number  of  key  areas  in  which  more  work  is  required. 

This  session  identified  76  attributes  of  a  software  development  project  for  consideration. 
These  attributes  were  organized  into  7  different  classifications.  Of  the  76  attributes  identified, 
13  top  attributes  were  highlighted  as  most  relevant  to  the  potential  success  of  using  CASE  on 
a  particular  project.  Of  these,  it  was  noted  that  preconditions  and  management  factors  far  out¬ 
weighed  technical  and  tool  issues. 

This  session  also  developed  a  list  of  13  recommendations  which,  when  implemented,  would 
do  the  most  to  ensure  the  success  of  using  CASE  on  a  particular  project.  An  abbreviated  ver¬ 
sion  of  these  recommendations  is  listed  below: 
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•  Develop  a  plan  for  CASE  adoption. 

•  Create  a  metrics  program. 

•  Establish  a  dedicated  process,  methods,  and  tools  group. 

•  Establish  a  management  mandate  for  automated  process,  methods,  and 
tools. 

•  Select  CASE  tools  that  are  extensible. 

•  Modify  MIL  STD  DIDS  to  focus  on  methods  and  plans  for  CASE  utilization. 

•  Designate  a  CASE  adoption  leader  with  a  mandate  for  action. 

•  Establish  or  join  CASE  adoption  societies. 

•  Identify  incentives  and  rewards  for  CASE  adoption. 

•  Create  a  CASE  adoption  risk  reduction  program. 

•  Establish  a  plan  for  up-front  and  continued  training  and  incentives  for  CASE 
tools. 

•  Provide  adequate  schedule  flexibility  for  CASE  adoption. 

•  Establish  a  lessons-leamed  CASE  tools  usage  database. 

2.4  Developing  a  Realistic  Estimate  for  CASE  Tool  Adoption 

The  aim  for  this  session  was  the  development  of  a  core  cost  estimation  framework  to  aid  oth¬ 
ers  in  preparing  detailed  CASE  budgets.  This  CASE  budget  framework  is  aimed  at  developing 
guidelines  for  determining  the  appropriate  amounts  of  people,  time,  and  money  needed  for 
CASE  tool  adoption. 

There  were  three  main  products  from  this  session: 

•  A  list  of  51  CASE  economic  issues 

•  Two  summary  tables: 

•  CASE  Adoption  Life-Cycle  Estimate  Matrix 

•  CASE  Adoption  Principle  Cost  Estimate  Matrix 

•  An  action  plan  for  further  investigation  and  refinement  of  this  preliminary 
CASE  Adoption  Economic  Model 

These  51  CASE  economic  issues  were  divided  into  6  categories: 

•  Process 

•  Management 

•  Economics 

•  Technical 
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•  Standards 


•  Implementation 

The  two  summary  tables,  the  CASE  Adoption  Life  Cycle  Estimate  Matrix  and  CASE  Adoption 
Principle  Cost  Estimate  Matrix,  provide  a  quick  overview  of  the  major  economic  factors  perti¬ 
nent  to  CASE  adoption.  In  addition,  they  attempt  to  highlight  those  elements  that  are  primary 
cost  drivers.  Overall,  these  tables  are  designed  to  encourage  potential  planners  to  consider  a 
wide  range  of  factors  that  can  influence  the  total  cost  of  CASE  adoption. 

To  achieve  all  of  the  session’s  original  mission  objectives,  further  effort  coordinated  by  the  SEI 
to  complete  the  design  of  the  CASE  cost  model  is  necessary.  When  completed,  this  CASE 
cost  model  would  consist  of  a  set  of  estimation  algorithms,  structured  like  the  COCOMO  soft¬ 
ware  cost  estimate  model,  and  a  guide  book  in  its  use. 

For  those  seeking  detailed  information  about  specific  tools  and  vendors,  a  set  of  CASE  re¬ 
source  pointers  was  assembled. 

2.5  Making  the  CASE  Tool  Fit  the  Organization  and  the 
Organization  Fit  the  CASE  Tool 

This  session  examined  changes  that  improve  the  chances  for  successful  CASE  tool  adoption. 
Characteristics  of  tools  and  organizations  that  facilitate  or  inhibit  CASE  adoption  were  exam¬ 
ined.  Each  characteristic  was  discussed  in  terms  of  the  following  factors  (as  applicable): 

•  Definition 

•  Examples 

•  How  to  implement 

•  Risks 

Listed  below  is  a  summary  of  the  four  characteristics  within  each  category: 

1 .  Tool  characteristics  that  facilitate  CASE  adoption 

•  Customizable 

•  Integratable 

•  Vendor  support 

•  Extensibility 

•  Documentation 

•  Platform  independence 

2.  Tool  characteristics  that  inhibit  CASE  adoption 

•  Failure  to  adopt  industry  trends 

•  Poor  performance 

•  Tool  proprietary  methodologies 


6 


CMU/SEI-91-TR-14 


•  Single-user  versus  multi-user  tools 

3.  Organizational  characteristics  that  facilitate  CASE  adoption 

•  Defined/understood  processes  and  standards 

•  Training 

•  Communication 

•  Management  support  for  implementation 

•  Ongoing  support 

4.  Organizational  characteristics  that  inhibit  CASE  adoption 

•  Cost 

•  Maintenance  versus  new  development 

•  Heterogeneous  development  environment 
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Adoption  Life  Cycle  and  Roles 


3.1  Theme  Description 

The  purpose  of  the  Adoption  Life  Cycle  and  Roles  session  was  to  identify  the  key  roles,  activ¬ 
ities,  and  issues  that  must  be  addressed  in  a  typical  adoption  life  cycle  for  CASE. 


3.2  Goal 

The  goal  of  this  workshop  session  was  to  complete  a  matrix  illustrating  suggested  entry  and 
exit  criteria  and  action  to  take  for  each  adoption  life-cycle  phase,  and  issues  to  pay  attention 
to  for  each  of  the  appropriate  roles  in  a  particular  adoption  phase.  This  matrix  is  not  definitive, 
but  should  provide  a  good  model  for  change  agents  to  use  when  planning  and  executing  a 
CASE  adoption  in  their  organizations. 

3.3  Process 

Starting  with  a  practical  adoption  model  suggested  by  Barbara  Bouldin  [4],  we  examined  the 
actions  in  each  life-cycle  phase  that  foster  adoption.  We  also  considered  the  issues  and  con¬ 
straints  that  typically  arise.  Finally,  we  developed  a  prototype  set  of  entry  and  exit  criteria  for 
each  phase.  We  looked  at  the  roles  that  are  key  to  success  in  each  adoption  phase,  and  at 
the  impact  of  each  role  on  the  overall  success  of  adoption.  We  documented  all  this  information 
in  the  form  of  a  matrix,  with  the  roles  on  the  horizontal  axis,  the  life-cycle  phases  along  the 
vertical  axis,  and  each  cell  containing  entry  and  exit  criteria  as  well  as  actions  and  issues.  (See 
Table  1  for  a  view  of  the  empty  matrix) 

To  limit  the  scope  of  our  work  and  focus  our  session,  we  assumed  that  we  were: 

•  Working  to  describe  the  adoption  of  a  CASE  tool  that  addressed  software 
design. 

•  Describing  the  adoption  of  the  design  method  embedded  in  the  tool. 

•  Dealing  with  a  cohesive  organizational  unit,  no  larger  than  about  200 
people,  having  multiple  projects,  and  reporting  to  one  manager. 

•  Dealing  with  a  manager  who  had  control  over  resources  and  could  make  a 
decision  that  this  organization  would  or  would  not  adopt  the  CASE  tool. 

•  Viewing  the  adoption  process  from  inside  the  adopting  organization. 

We  were  asking,  in  effect,  what  actions  by  members  of  that  organization  were  needed  to  ex¬ 
pedite  the  adoption.  These  actions  need  to  be  considered  in  the  context  of  an  organization. 
Smaller  organization  units  would  keep  the  roles  described  here,  but  scale  down  the  effort  ac¬ 
cordingly.  Smaller  organization  units  would  keep  the  roles  described,  but  scale  down  the  effort. 
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CASE  Adoption:  Roles  and  Life  Cycle 
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Adapted  from  B.  Bouldin,  Agents  of  Change,  Yourdcm  Press,  1989 


Table  1  CASE  Adoption:  Roles  and  Life  Cycle 

The  approach  to  the  session  choson  by  the  session’s  facilitators,  John  Maher  and  Priscilla 
Fowler,  provided  an  efficient  structure  for  participants  to  pool  their  collective  experience.  Boul- 
din's  adoption  life  cycle  is  representative  of  a  number  of  life  cycles  that  appear  in  the  technol¬ 
ogy  transition  literature  (see,  for  example,  [25]  and  [6]).  It  was  selected  for  three  reasons:  first, 
it  exists  in  published  form;  second,  it  was  derived  from  an  industrial  setting  where  CASE  tools 
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were  being  adopted;  and  third,  beginning  with  an  existing  and  representative  model  allowed 
participants  to  focus  on  the  actual  steps  needed  by  players  in  the  adoption  process.  It  was  as¬ 
sumed  that  a  session  participant  or  anyone  reading  this  material  subsequently  would  need  to 
tailor  it,  especially  its  terminology,  to  suit  local  environments  and  customs.  At  the  beginning  of 
the  session,  the  approach  was  reviewed  with  participants  and  agreed  to  with  slight  modifica¬ 
tions. 

John  Maher  began  the  session  with  a  brief  tutorial,  ‘Transitioning  New  Technologies,”  to  intro¬ 
duce  some  concepts  that  would  be  needed  to  understand  and  fill  the  matrix.  Most  importantly, 
he  defined  the  terms  used  in  the  horizontal  axis  of  the  matrix:  upper  management  and  line 
management  (sponsors),  product  champion,  change  agent,  pilot  project  team,  and  individual 
users  (targets).  At  the  upper  management  level,  the  sponsor  provides  resources,  strategic  and 
policy  direction,  and  final  approval  to  proceed  with  the  adoption  of  CASE.  At  the  line  manage¬ 
ment  level,  the  sponsor  may  authorize  resources  and  direct  efforts  toward  planning  for  CASE 
adoption  and  experimental  use.  The  product  champion  is  the  individual  who  initially  introduces 
the  idea  of  a  particular  CASE  tool  or  type  of  tool,  and  informally  advocates  it,  calling  it  to  the 
attention  of  others.  The  change  agent  is  an  individual  or  team,  drawn  from  line  management 
or  software  personnel,  who  does  the  detailed  planning  and  implementation  of  the  CASE  adop¬ 
tion.  The  pilot  project  team  tries  the  CASE  tool  for  the  first  time  on  behalf  of  the  larger  organi¬ 
zational  unit.  The  target  users  are  the  remainder  of  the  organization  who  will  eventually  adopt 
the  CASE  tool.  “Adoption"  is  defined  as  routine,  everyday  use  of  a  CASE  tool  or  technology. 
More  background  on  these  definitions  can  be  taken  from  the  details  of  the  matrix  itself. 

3.4  Adoption  Life-Cycle  Phases 

During  the  session,  definitions  of  the  adoption  life-cycle  phases,  initially  adapted  from  Bouldin, 
evolved: 

1.  Assesr  *he  Need.  The  champion  considers  how  a  CASE  technology 
might  improve  the  manner  in  which  the  organization  develops  software 
and  collates  information  about  what  CASE  tools  might  address  the 
problems  the  organization  faces. 

2.  Select  Candidate  Products.  A  quick  survey  of  likely  CASE  products  is 
made  and  candidates  are  selected  which  meet  the  organization's 
requirements. 

3.  Evaluate  Candidate  Products.  One  or  two  CASE  products  are  tested  by 
users  working  in  projects  typical  of  the  organization.  The  best  product  is 
selected  as  a  candidate  for  broader  use  within  the  organization. 

4.  Present  Product  to  Management,  Users.  The  product  chosen  is 
presented  to  management  and  potential  users,  with  information  on  its 
costs,  benefits,  application,  and  projected  results. 
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5.  Gather  User  Information.  Details  on  the  broader  target-user  community 
are  gathered  as  input  to  planning  the  implementation  across  the  entire 
organization. 

6.  Plan  the  Implementation.  Detailed  plans  are  prepared. 

7.  Implementation  and  Ongoing  Support.  The  selected  CASE  tool  is 
installed  in  projects  across  the  organization  and  support  services  are 
organized  and  delivered. 

3.5  Matrix  of  CASE  Adoption  Roies  and  Life  Cycle 

This  section  is  organized  by  horizontal  rows  in  the  CASE  adoption  matrix  that  was  developed. 
Within  each  row,  information  is  grouped  by  roles.  The  entry  under  each  role  within  a  row  rep¬ 
resents  one  cell  of  the  matrix.  There  are  7  rows  (life-cycle  phases)  and  6  columns  (roles),  for 
a  total  of  42  cells.  Not  all  cells  are  populated — in  cases  that  don't  make  sense,  cells  are  left 
blank.  Each  cell  is  identified  in  two  ways.  First,  the  cell  intersection  is  titled  by  Role  (Life-Cycle 
Phase).  Second,  there  is  a  table  icon  next  to  each  title.  This  icon  highlights  the  relative  position 
of  that  cell  in  the  overall  table.  Each  cell  contains  Entry  Criteria  (when  and  why  this  step  is  tak¬ 
en),  Action(s)  taken,  Issues,  and  Exit  Criteria  (when  each  step  is  completed  and  how  you 
know). 

3.5.1  Assess  the  Need 
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3.5.1.1  Upper  Management  (Assess  the  Need) 

Entry  Criteria 

•  Upper  management  generally  favors  quality,  productivity 

•  Business  condition  exists  that  gets  attention 

•  Upper  management  may  be  ignorant  of  opportunities 

•  Organization  has  a  strategic  plan 

•  CASE  may  be  required  in  statement  of  work  (SOW) 

•  Turnover  in  upper  management  leads  to  new  executive  with 
agenda 

Actions 


•  Upper  management  may  initiate  a  look  into  problems, 
opportunities  (e.g.,  create  a  taskforce) 
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•  Upper  management  may  seek  outside  sources  of  education 

Issues 

•  Influence  of  external  business  environment  to  move  organization 
in  a  particular  direction 

•  Direct  cost  on  program  and  schedule 

•  How  much  the  business  of  the  organization  will  depend  on 
software 

•  Improvement  and  quality 

•  Available  work  force 

•  Increasing  complexity  of  software 

Exit  Criteria 

•  Report  of  task  force,  if  any 

•  Decision  to  look  at  or  abandon  candidate  technologies 


ml 
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3.5.1 .2  Une  Management  (Assess  the  Need) 
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Entry  criteria 
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•  Low  productivity 

•  Over  budget 

•  Not  enough  people  to  handle  change  requirements 

•  Management  support  of  concept  of  productivity,  quality 

•  Directive  from  upper  management 

•  Exposure  to  new  technology 
Actions 

•  Authorize  basic  information  gathering  and/or  education 
(conferences,  literature,  etc.) 

•  Interpret  and  support  upper  management  decisions 

•  Influence  and  be  influenced  by  upper  management 

•  Provide  guidance  for  next  stage  activities 
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Phases 


•  Gather  information  from  peers,  within  own  group 

Issues 

•  Driven  by  cost,  schedule,  people 

•  Turnover  of  personnel,  with  influx  of  new  people 

•  Low  morale 
Exit  Criteria 

•  Decision  to  accept,  argue  with  or  reject  recommendation  to 
proceed 

•  Commitment  of  people  to  work  on  the  next  stage 

■  3.5.1 .3  Product  Champion  (Assess  the  Need) 

Entry  Criteria 

•  Perception  of  need 
•  Willingness  to  irsue  issue 
•  Dissatisfaction  with  current  state  of  affairs 
•  Ability  to  envision  future  state 
•  Knowledge  of  organization 
•  Ability  to  communicate  vision,  need 
•  Respect  from  organization  members 
Actions 

•  Test  management’s  awareness  of  issues 

•  Begin  "awareness  building”  activities  (influence  peers,  influence 
planning  process,  arrange  demos,  give  talks) 

•  Begin  building  business  case  for  CASE 

•  Gather  and  test  users'  awareness  of  issues  and  need 

Issues 

•  Job  security 

•  Management  attitude,  inertia 
•  Corporate  policy,  culture 
•  Politics 
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•  Opportunities  for  information  sharing 

•  Stability  or  degree  of  entrenchment  of  current  system 

Exit  Criteria 

•  Management  convinced  of  need  to  look  at  candidate  tools  and 
methods 

•  Change  agent  appointed 


3.5.14  Change  Agent  (Assess  the  Need) 

See  Product  Champior. 


Pilot  Project  Team  (Assess  the  Need) 


3.5.1. 6  Target  Users  (Assess  the  Need) 

Entry  Criteria 

•  Champion  or  management  contact 
Actions 


•  Provide  input  to  champion  and/or  management  on  work  issues, 
needs,  potential  solutions 

Issues 


•  Parochial  views  of  problems 
Exit  Criteria 


3.5.2  Select  Candidate  Products 


3.5.2.1  Upper  Management  (Select  Candidate  Products) 
Entry  Criteria 

•  Commitment  to  look  at  candidate  products 
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Phases 


•  Commitment  to  make  a  selection 

Actions 

•  Authorize  funds,  resources,  responsibility 

•  Set  a  time  frame 

•  Tell  line  management  to  determine  requirements  and  recommend 
alternatives 

Issues 

•  Relationships  with  potential  vendors 

•  Consistency  with  corporate  goals,  strategies 

Exit  Criteria 

•  Management  report  on  requirements  and  alternative  products  to 
meet  the  need 


3.5.2^  Line  Management  (Select  Candidate  Products) 

Entry  Criteria 

•  Directive  from  upper  management  or  individual  initiative  to  look  at 
alternative  tools  and/or  methods 

•  Identification  of  funding  source 

Actions 


•  Authorize  and/or  direct  requirements  analysis 

•  Authorize  selection  of  candidate  products  (methodology  before 
tool) 

•  Select  and  assign  individual  or  team  to  selection  task 

•  Communicate  formal  role  of  individual  or  team  to  organization 

•  Oversee  and  monitor  selection  process 

•  Allocate  funds  for  selection  process 

•  Direct  creation  of  plan  for  selection 
Issues 


16 


Relationships  with  potential  vendors 
Constraints  of  existing  purchasing  practices 
Constraints  of  security  requirements 
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Phases  Phases 


•  Methodology  and  tool  fit  between  process  and  organization 

•  Education  of  line  management 

•  Schedule  slippage  with  current  projects  due  to  reallocation  of 
resources  to  selection  task 

Exit  Criteria 

•  Report  on  candidate  products  received 

•  Methodology  selected 

•  Decision  made  to  proceed 


3.5.2L3  Product  Champion  (Select  Candidate  Products) 

Entry  Criteria 

•  Continuing  interest,  dissatisfaction  with  current  state 

Actions 


•  Influence,  lobby  for  method  and  tool  among  management,  peers 

•  Provide  expertise  on  method,  tool 
Issues 

•  Champion  and  change  agent  conflict  on  goals,  procedures,  etc. 

•  Champion's  support  of  organization  decision 

•  Impact  of  champion  work  on  regular  job 
Exit  Criteria 


3.5.2L4  Change  Agent  (Select  Candidate  Products) 
Entry  Criteria 

•  Assignment  to  develop  plan  for  selection 

Actions 


•  Documents  the  adoption  life-cycle  process  (lessons  learned) 

•  Develops  plan  for  selection 

•  Works  with  team  to  recommend  tool  and  method,  executes  plan, 
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Phases  Phases 


prepares  report 
Issues 

•  Adequacy  of  resources,  time 

•  How  legitimacy  of  role  is  conveyed  to  organization 

•  Competence  of  agent  in  methods  and  tools 

•  Competence  of  agent  as  change  agent 

•  Rewards  and  risk  for  agent  role 

•  How  to  deal  with  reluctant  agent 
Exit  Criteria 

•  Methodology,  tools  selected  for  evaluation 

•  Report  prepared  and  delivered  to  management 


3.5.25  Pilot  Project  Team  (Select  Candidate  Products) 

Entry  Criteria 

Actions 

Issues 

Exit  Criteria 


3.5.26  Target  Users  (Select  Candidate  Products) 

Entry  Criteria 

•  Announcement  of  candidate  selection  process 

•  Announcement  of  change  agent 
Actions 


•  Respond  to  “idea"  of  innovation 

•  Provide  input  to  selection  plan 

•  Attempt  to  influence  selection  of  pilot  project,  methods,  tools 

Issues 


•  Impact  on  users’  projects,  schedules 
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•  Learning  curve  (contact,  awareness,  understanding) 

•  Unclear  goals,  information  (affects  expectations) 

•  Acceptance  of  change  agent 

Exit  Criteria 

•  Input  provided  to  management,  agent 

•  Announcement  of  candidate  products  to  evaluate 

3.5.3  Evaluate  Candidate  Products 


3.5.3.1  Upper  Management  (Evaluate  Candidate  Products) 
Entry  Criteria 

•  List  of  candidate  methods,  tools  to  evaluate 

•  Commitment  to  evaluate 
Actions 


•  Authorize  resources  for  evaluation 

•  Communicate  commitment  to  strategic  goals 

•  Provide  ongoing  support  and  guidance  from  business  perspective 

•  Make  decision  on  recommended  product 
Issues 


•  Impatience  with  process 

•  Tendency  to  meddle  with  technical  issues 

Exit  Criteria 


•  Decision  communicated  to  organization  on  recommended 
product 


3.S.3.2  Una  Management  (Evaluate  Candidate  Products) 

Entry  Criteria 
Actions 

•  Commit  resources  to  evaluation  task  (people,  $$,  time) 
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Phases 


•  Support  preparation  of  business  case 

•  Select  pilot  projects 

•  Deflect  outside  pressure  on  evaluation  team 

•  Facilitate  procurement  of  product 

•  Approve  plan  for  pilot  testing 

•  Monitor  progress  of  evaluation 

•  Manage  expectations  (up,  across,  and  down) 

•  Recommend  product  to  implement 

•  Foster  consensus  among  all  those  at  risk 
Issues 

•  Risk  associated  with  trial  use  of  new  product 

•  Persistence  of  management  in  providing  support 

•  Estimates  (time,  money,  etc.)  that  are  too  small  for  task 

•  Risk  of  poor  decision  due  to  incomplete  data 
Exit  Criteria 

•  Business  case  completed  and  product  recommended 


3A3  J  Product  Champion  (Evaluate  Candidate  Products) 

Entry  Criteria 

Action 


•  Provide  expertise  on  methodology,  tool 

•  Influence  selection  of  pilot  project 
Issues 


•  Conflict  with  change  agent  on  goals,  procedures,  etc. 

•  Will  champion  support  organization  decision? 

•  Impact  of  championship  on  regular  job 
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•  Influence  on  pilot  execution 

Exit  Criteria 


3.S.3.4  Change  Agent  (Evaluate  Candidate  Products) 

Entry  Criteria 
Actions 

•  Document  the  adoption  life-cycle  process 

•  Develop  criteria  and  metrics  for  pilot  selection,  product  evaluation, 
trial  evaluation 

•  Recommend  pilot  projects 

•  Facilitate  team  development  (evaluation  team,  pilot  project  teams, 
etc.) 

•  Develop  plan  for  pilots 

•  Develop  contract  with  tool  vendors 

•  Procure  products  to  evaluate 

•  Fa  Jlitate  training  of  pilot  teams 

•  Document  software  engineering  process 

•  Monitor  pilot  execution  and  measure  effectiveness 

•  Evaluate  trial  results 

•  Decide  which  tool  and  method  to  recommend 

•  Build  business  case  with  support  from  management 

•  Report  to  line  management  on  progress 

•  Monitor  budget  and  schedule  of  trial  projects 

•  Manage  pilot  effort 

•  Conduct  external  evaluation  of  vendor,  tool 

Issues 

•  Management  of  risk  during  pilot  implementation 

•  Management  of  expectations  in  management,  pilot  teams, 
vendors 

•  Management  of  interface  with  everyone  else 

•  Risk  of  partiality 


•  Potential  lack  of  change  agent  and  managerial  skills 

•  Inability  of  pilot  team  to  carry  through  test  and  meet  production 
schedule 

•  Lack  of  authority  to  make  decisions  for  pilot  effort 

•  Inadequate  access  to  line  management,  resources 

•  How  best  to  develop  metrics  for  trial  results 

•  How  to  compare  results  across  pilot  teams 
Exit  Criteria 

•  Recommended  tool(s)  and  method(s)  identified 

•  Business  case  built  and  delivered  to  management 


3.S.3.5  Pilot  Project  Team  (Evaluate  Candidate  Products) 

Entry  Criteria 

Actions 


•  Participate  in  developing  pilot  plan 

•  Be  trained  in  use  of  method  and  tool 

•  Execute  pilot  project  according  to  pilot  plan 

•  Collect  metrics  during  pilot  testing 

•  Provide  feedback  on  method  and  tool  use 
Issues 

•  Conflict  between  schedule  and  task  assignment  (pilot  and  other 
jobs) 

•  Separation  of  project  tasks  from  product  evaluation  tasks 

•  Consistency  of  application  across  team  of  the  tools  or  methods 


22 


CMU/SEI-91-TR-14 


•  Rewards  and  risks  for  pilot  implementation 

Exit  Criteria 


3.5.3.6  Target  Users  (Evaluate  Candidate  Products) 

Entry  Criteria 
Actions 

•  Respond  to  “idea"  of  innovation 

•  Attempt  to  influence  selection  of  pilot  project,  methods,  tools, 
metrics 

Issues 

•  Impact  on  users'  projects,  schedules 

-  Learning  curve  (contact,  awareness,  understanding) 

•  Undear  goals,  information  (affects  expectations) 

-  Acceptance  of  change  agent 

•  Acceptance  of  pilot  project  as  “typical”  of  their  work 
Exit  Criteria 

•  Input  provided  to  management,  agent 

•  Pilot  results/dedsion  known 

3.5.4  Present  Product  to  Management,  Users 


35.4.1  Upper  Management  (Present  Product  to  Management,  Users) 

Entry  Criteria 
Actions 

•  Commit  time,  staff,  money 

•  Identify  target  organizations  for  implementation 

•  Make  public  commitment  to  information  gathering,  presentation  of 
method  and  tool 


Phases  Phases 


•  Handle  interface  with  higher  management 
Issues 

•  Potential  for  lack  of  understanding 

•  Potential  for  diminishing  interest  in  effort 

•  Potential  for  “cold  feet”  due  to  cost,  risk 

Exit  Criteria 

•  Decision  to  go  ahead  with  Implementation 


15.4.2  Line  Management  (Present  Product  to  Management,  Users) 

Entry  Criteria 

Actions 


•  Allocate  time,  staff,  $$ 

•  Identify  target  projects  for  implementation 

•  Make  public  commitment  to  information  gathering,  presentation  of 
method  and  tool 

•  Handle  interface  with  superions,  peers,  subordinates 
Issues 


•  Potential  for  lack  of  understanding 

•  Potential  for  diminishing  interest  in  effort 

•  Potential  for  “cold  feet"  due  to  cost,  risk 

•  Support  from  upper  management 
Exit  Criteria 


•  Recommend  decision  to  implement 


■  3.5.4.3  Product  Champion  (Present  Product  to  Management,  Users) 
Entry  Criteria 
Actions 

•  "Sell”  the  method  and  tool  to  users,  management 
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•  Take  part  in  demos 

Issues 

•  Satisfaction  with  pilot  results,  recommendation 

•  Champion  and  change  agent  conflict  on  goals,  procedures,  etc. 

•  Support  of  organization  decision 

•  Impact  of  championship  on  regular  job 

•  Potential  for  defeated  champions  to  resist  decision 
Exit  Criteria 

•  Satisfaction  with  outcome  (continues  as  champion) 

•  Dissatisfaction  with  outcome  (because  no  longer  a  player) 

•  Presentations  to  management,  users  (if  participant) 


3.5.44  Change  Agent  (Present  Product  to  Management,  Users) 

Entry  Criteria 
Actions 

•  Document  the  adoption  life-cycle  process  (lessons  learned) 

•  Undertake  marketing,  sales  campaign 

•  Collect  feedback,  make  notes  for  implementation  planning 

•  Follow  up  with  management  for  open  action  items 

•  Seek  sponsorship 
issues 

•  Inexperience  in  marketing,  sales 

•  Lack  of  confidence  in  method  and  tool  decision 

Exit  Criteria 

•  Presentations  to  management,  users  completed 

•  Management  decision  on  implementation 
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Phases  Phases 


■  3.5.4.5  Pilot  Project  Team  (Present  Product  to  Management,  Users) 
Entry  Criteria 
Actions 

•  Supports  marketing  effort 
•  Provides  demos 
•  Influences  target  users 

Issues 

*  Acceptance  of  method/tool 
•  Major  dissension  in  project 
Exit  Criteria 

•  Demos  and  presentations  completed  (as  requested) 


■  &5.4.6  Target  Users  (Present  Product  to  Management,  Users) 
Entry  Criteria 
Actions 

•  Attend  presentations/demos 
•  Voice  concerns,  issues,  support  (as  appropriate) 

Issues 

•  Parochial  view  of  work,  method  and  tool,  etc. 

•  Split  in  support  by  user  community 
•  Indifference  to  innovation 
•  Perception  that  method/tool  doesn’t  fit  need 
•  Low  morale 

•  Unsystematic  implementation 

Exit  Criteria 

•  Presentations/demos  done 
•  User  input  voiced 
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Phases  Phases 


3.5.5  Gather  User  Information 


M3.5.5.1  Upper  Management  (Gather  User  Information) 

Entry  Criteria 
Actions 

•  Authorize  activity  to  gather  information 
•  Voice  expectations  about  timetables,  results 
•  Address  questions  as  necessary 
•  Authorize  preparation  of  implementation  plan 

Issues 

•  Exaggerated  expectations  of  near-term  results 
•  Support  may  not  be  unanimous 
Exit  Criteria 

•  Implementation  plan  preparation  authorized 


iRoles 

MR 


3.S.5.2  Lino  Management  (Gather  User  Information) 

Entry  Criteria 

Actions 


•  Identify  key  people  for  implementation  planning 

•  Initiate  and  monitor  activity  to  gather  information 

•  Voice  expectations  about  timetables,  results 

•  Address  questions  as  necessary 

•  Communicate  information-gathering  effort 

•  Gather  and  maintain  support  of  peers 

•  Maintain  an  atmosphere  for  open  dialogue 
Issues 


•  Exaggerated  expectations  of  near-term  results 
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Phases  Phases 


•  Support  may  not  be  unanimous 

Exit  Criteria 

•  Information  reported  to  management 

•  Planning  team  identified  and  assigned  to  work  with  agent 


M3.5.5.3  Product  Champion  (Gather  User  Information) 

Entry  Criteria 
Actions 

•  Provides  information 
•  Clarifies  how  method  and  tool  can  be  used 
Issues 

•  Biased 
•  May  oversell 

•  May  interfere  with  orderly  data  gathering  process 
Exit  Criteria 


■[es  3.5.54  Change  Agent  (Gather  User  Information) 

111  Entry  Criteria 
LLJ  Actions 

•  Document  the  adoption  life-cycle  process 
•  Prepare  plan,  instruments  for  gathering  data 
•  Identify  key  data  sources 
•  Gather  data 

•  Facilitate  worker-level  consensus 
•  Raise  issues  with  management 

Issues 

•  Covert  resistance/dishonesty  of  users 
•  Lack  of  experience  in  gathering  data  systematically 
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Phases  Phases 


•  Attempts  to  sabotage  process 

•  Confidentiality  of  data,  attribution 

•  Credibility  of  agent,  sources 

Exit  Criteria 

•  Data  gathered  and  ready  for  factoring  into  planning 

•  Data  reviewed  with  planning  team 


3.5.5 JS  Pilot  Project  Team  (Gather  User  Information) 

Entry  Criteria 

Actions 


•  Support  change  agent 

•  Provide  conduit  of  Information  to  and  from  users 
Issues 


•  Inaccurate  representation  of  users 

•  Credibility  (if  pilot  not  initially  successful) 

Exit  Criteria 


Ftotes 

SB 


3.S.5.6  Target  Users  (Gather  User  Information) 

Entry  Criteria 

Actions 


•  Provide  information,  concerns,  perspective  to  agent 

•  Move  toward  consensus  by  looking  at  differences,  similarities  in 
user  group 

•  Participate  actively  in  data  gathering  effort 

•  Keep  an  open  mind 
Issues 


•  Parochial  view  of  effort 
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Phases 


•  Polarization  of  user  group 
Exit  Criteria 

•  Interviews,  etc.,  completed 

3.5.6  Plan  the  Implementation 


■  3.5.6.1  Upper  Management  (Plan  the  Implementation) 
Entry  Criteria 
Actions 

•  Determine  sources  of  funding 
•  Authorize  funding,  resources,  etc. 

•  Approve  or  reject  implementation  plan 
•  Convey  ongoing  support  of  effort 
•  Maintain  external  interfaces 
Issues 

•  Cost  of  implementation 
•  Funding  sources 

•  Impact  on  ongoing  projects,  resources 
•  Link  with  strategic  goals 
•  Legal  ramifications 
Exit  Criteria 

•  Implementation  decision  made 
•  Funds  for  implementation  authorized 
•  Sources  for  funding  determined 


30 


CMU/SEI-91  -TR-1 4 


3.S.6.2  Une  Management  (Plan  the  Implementation) 

Entry  Criteria 
Actions 

•  Direct  and  monitor  plan  development 

•  Recommend  plan  to  upper  management 

•  Provide  support,  time  for  planning 

•  Convey  impact  of  decision  to  organization 

•  Monitor  staff  morale 

•  Convey  public  support  for  effort 

•  Facilitate  consensus  among  peers,  subordinates 

•  Maintain  an  atmosphere  for  open  dialogue 
Issues 

•  Impact  of  planning,  implementation  on  ongoing  projects 

•  Impact  on  organization  morale 

•  Maintenance  of  open  atmosphere  for  discussion 

Exit  Criteria 

•  Plan  to  recommend  to  upper  management 

•  Sense  of  level  of  support  in  organization 


3.5.64  Product  Champion  (Plan  the  Implementation) 

Entry  Criteria 

Actions 

•  Provides  information  for  planning 

•  Provides  input  on  training  issues 

Issues 
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Biased 
May  oversell 

May  underestimate  training  needs 
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Phases  Phases 


•  May  interfere  with  orderly  planning  process 

Exit  Criteria 


•  Input  to  plan  completed 


■  3.S.6.4  Change  Agent  (Plan  the  Implementation) 

Entry  Criteria 

•  Assignment  to  develop  plan 

Actions 

•  Document  the  adoption  life-cycle  process 

•  Organize  and  build  planning  team 

•  Lead  development  of  plan  addressing  organization-wide 
issues/implementation 

•  Chair  the  planning  team 

•  Monitor  morale,  progress  in  team,  users 

•  Maintain  sponsorship 

•  Develop  contingency  plans 

Issues 

•  Competence  of  change  team 
•  Workload  for  change  team 
•  Time  management 
•  Shifting  priorities 

•  Adequate  information  or  access  to  information 

Exit  Criteria 

•  Plan  submitted,  revised,  and  accepted 


M  345.6.5  Pilot  Project  Team  (Plan  the  Implementation) 
Entry  Criteria 
Actions 

•  Support  planning  team 
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Phases 


•  Provide  conduit  of  information  to  and  from  users 

•  Provide  input  for  plan 

•  Review  plan 
Issues 

•  May  not  typify  the  user  population 

Exit  Criteria 

•  Plan  reviewed 


|ies  3.5.6.6  Target  Users  (Plan  the  Implementation) 

Ifj  Entry  Criteria 
ffl  Actions 

•  Provide  information,  concerns,  perspective  to  planning  team 

•  Review  plan  (sample  of  users):  work  estimation,  timing,  support, 
rewards  for  implementation,  learning  curve,  etc. 

•  Begin  to  rework  existing  schedules,  if  necessary 

Issues 

•  Parochial  view  of  effort 
•  Polarization  of  user  group 
•  Impact  of  implementation  on  current  projects 
•  Confidentiality  of  feedback 
•  Rewards  for  implementation 
Exit  Criteria 

•  Plan  reviewed  by  sample  of  population 
•  In-progress  rework  scheduled,  as  required 
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Phases  Phases 


3.5.7  Implementation  and  Ongoing  Support 


M  3.57.1  Upper  Management  (Implementation  and  Ongoing  Support) 

Entry  Criteria 
Actions 

•  Convey  continuing  support/sponsorship 
•  Link  implementation  success  with  reward  system 
•  Initiate  policy  changes,  updates 

•  Authorize  funding,  resource  allocation  updates  as  necessary 
•  Manage  external  interface 

•  Actively  participate  in  communication,  symbolic  leadership,  etc., 
in  support  of  effort 

•  Monitor  impact  of  implementation  and  ongoing  activity 
•  Reward,  recognize,  &  publicize  success 
Issues 

•  Level  of  continuing  sponsorship 
•  Implementation  problems,  e.g.,  cost  overruns 
•  Other  pressing  issues 
Exit  Criteria 

•  Implementation  complete:  method  and  tool  routine  part  of 
business 


3-57.2  Line  Management  (Implementation  and  Ongoing  Support) 

Entry  Criteria 

Actions 


•  Implement  plan 

•  Monitor  progress,  results 

•  Facilitate  surfacing  and  resolution  of  issues 

•  Facilitate  establishment  of  ongoing  implementation/support 
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Phases 


activities  (e.g.,  vendor  support) 

•  Develop  or  direct  development  of  policies  that  support  method 
and  tool 

•  Ensure  that  people  use  the  product  correctly 

•  Provide  ongoing  sponsorship 

•  Manage  interfaces:  peer,  superior,  subordinate 

•  Reward  and  publicize  success,  celebrate 

•  Allocate  and  adjust  resources  during  implementation 

•  Adjust  plan  as  necessary 
Issues 

•  Meeting  product  delivery  dates 

•  Managing  resistance;  maintaining  morale 

•  Providing  resources  for  support  (training,  consultation, 
equipment,  etc.) 

•  Managing  changes  in  management,  strategic  direction 

•  Reacting  to  staff  turnover,  reorganization 

Exit  Criteria 

•  Implementation  complete:  method  and  tool  routine  part  of 
business 


■  3.57.3  Product  Champion  (Implementation  and  Ongoing  Support) 

Entry  Criteria 
Actions 

•  Continue  to  provide  support  for  effort 
•  Celebrate  success 

Issues 

•  Re-entry  into  normal  work 
Exit  Criteria 

•  Implementation  complete:  method  and  tool  routine  part  of 
business 
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■  3.57.4  Change  Agent  (Implementation  and  Ongoing  Support) 

Entry  Criteria 
Actions 

•  Document  the  adoption  life-cycle  process 
•  Implement  plan  (see  notes) 

•  Monitor  progress 

•  Shift  direction  as  necessary:  negotiate  altering  plan 
•  Communicate  sponsor  support 
•  Provide  feedback  to  sponsors,  venders 
•  Manage  resistance 

•  Facilitate  development  of  formal  processes  and  procedures  (e.g., 
custom  user  guide,  draft  organization  policy,  etc.) 

•  Facilitate  establishment  of  ongoing  implementation  and  support 
activities  (e.g.,  vendor  support,  user  group) 

•  Monitor  status  of  vendor  in  marketplace 

•  Monitor  developments  in  tool  marketplace 

Issues 

•  Change  in  strategic  direction 
•  Change  in  organization,  personnel,  management 
•  Change  in  job 
•  Succession  planning 
•  Impact  of  new  technology 
Exit  Criteria 

•  Implementation  complete:  method  and  tool  routine  part  of 
business 
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3.5J.5  Pilot  Project  Team  (Implementation  and  Ongoing  Support) 

Entry  Criteria 
Actions 

•  May  “seed"  other  projects  with  expertise 

•  May  train  other  projects 

•  Provide  information  for  user  guide 

Issues 

•  Version  changes  that  make  experience  obsolete 

Exit  Criteria 

•  Implementation  complete:  method  and  tool  routine  part  of 
business 


■  3£.7.6  Target  Users  (Implementation  and  Ongoing  Support) 
Entry  Criteria 
Actions 

•  Get  training 
•  Use  method/tool 

•  Address  concerns,  issues,  problems  in  use 
•  Suggest  solutions  to  issues,  problems,  etc. 

•  Provide  informal  training  to  peers 
•  Participate  in  user  groups 
Issues 

•  Quality,  extent  of  support 
•  Learning  curve 
•  Rewards  for  implementation 
•  Turnover 

•  Impact  on  daily  work  habits 
•  Impact  on  schedule,  budget,  etc. 
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•  Communication  with  superiors,  agent 

Exit  Criteria 

•  Implementation  complete:  method  and  tool  routine  part  of 
business 
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Can  You  Get  the  Benefits  of  CASE  Without  Buying 
It? 


4.1  Theme  Description 

The  purpose  of  this  workshop  session  was  to  determine  which  benefits  (if  any)  could  be  de¬ 
rived  from  the  formal  specification  of  a  development  project  using  CASE  technology,  indepen¬ 
dent  of  the  CASE  tools  themselves. 

4.2  Goal 

The  output  of  this  workshop  session  was  a  set  of  positions  formalized  by  the  participants  about 
questions  that  were  discussed,  such  as: 

•  What  is  CASE? 

•  What  must  be  automated? 

•  What  cannot  be  automated? 

•  What  work  tasks  does  CASE  change? 

•  How  can  “not  buying  but  using"  be  sold  to  management? 

•  What  lessons  can  be  learned  from  workshop  participants’  own  experience? 

4.3  Process 

The  workshop  session  began  by  producing  the  output  of  the  workshop.  All  participants  played 
an  active  role,  such  as  being  a  scribe  on  one  of  8  flipcharts,  or  sharing  a  specific  experience 
that  others  had  not  been  exposed  to. 

The  workshop  session  focused  on  the  practitioners’  needs,  which  included  the  ability  to  com¬ 
municate  effectively  with  management. 

4.4  Results 

4.4.1  A  Definition  of  CASE 

In  general  terms,  CASE  technology  can  be  thought  of  as  "any  computer  based  assistance  that 
reduces  the  labor  intensity  of  project  development.  The  group  consensus  was  that  current  ori¬ 
entation  of  CASE  (Computer  Aided  Software  Engineering)  thinking  was  not  large  enough.  The 
group  suggests  a  higher-level  orientation  like  Computer-Aided  Project  Engineering  (CAPE). 

The  group  first  proposed  a  more  precise  definition  of  CASE.  It  was  noted  that  it  would  be  un¬ 
reasonable  to  consider  implementation  of  lower-level  development  tasks  (e.g.,  compilation, 
code  management,  debugging)  without  the  aid  of  tools.  Therefore,  it  was  agreed  that,  for  the 
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purposes  of  the  workshop  discussion,  “CASE”  would  mean  only  “upper  CASE"  (diagramming 
and  display)  tools  that  operated  on  diagram  types,  such  as: 

•  Data  flow  diagrams 

•  State  transition  diagrams 

•  Entity-relationship  diagrams 

•  Control  flow  diagrams 

•  Structure  charts 

4.4.2  An  Enabled  Benefit  of  CASE  Technology 

The  primary  benefit  of  CASE  tools  is  that  they  enable  a  defined  methodology.  A  methodology 
is  essentially  a  network  of  (iterative)  work  tasks.  To  benefit  effectively  from  CASE  technology, 
users  would  first  have  to  define  a  methodology  appropriate  to  their  development  process. 

Although  CASE  tools  (in  the  context  selected)  automate  the  diagramming  process,  they  are 
not  fundamentally  a  part  of  the  methodology.  It  was  decided  that,  on  this  level,  the  benefits  of 
CASE  technology  can  be  experienced  by  users  without  the  requirement  of  CASE  tool  adop¬ 
tion. 


4.4.3  The  Benefits  of  Automation 

As  part  of  the  session,  the  discussion  focused  on  the  types  of  tasks  (those  which  could  be  per¬ 
formed  manually  as  part  of  “not  buying”)  for  which  CASE  automation  was  useful.  The  group 
then  identified  these  tasks. 

The  group  felt  that  automation  should  not  control  the  development  process  or  methodology, 
but  rather  work  flexibly  in  support  of  the  project.  A  list  of  the  automated  tasks  and  associated 
support  desired  from  the  CASE  tools  would  then  include: 

•  Production  of  documentation 

•  Interface  connections  between  work  tasks 

•  Assistance  in  impact  analysis 

•  Project  formalism 

•  Integration  of  higher  levels  of  abstraction 

•  Enforcement  of  project  standards  and  procedures 
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4.5  Lessons  Learned 

Finally,  as  the  emphasis  of  the  session  was  on  CASE  without  tool  support,  the  group  dis¬ 
cussed  several  aspects  of  CASE  related  specifically  to  adoption  of  the  technology  through 
modification  or  installation  of  the  development  process: 

•  Many  methodology  decisions  give  inadequate  regard  to  cost. 

•  Management  underestimates  the  difficulty  of  change. 

•  Productivity  is  the  result  of  a  well-defined  process. 

•  Process  quality,  not  productivity,  must  be  the  focus  of  change. 

•  Product  quality  will  result  from  process  quality. 

•  Tools  will  evolve  in  support  of  a  viable  defined  methodology. 
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5  The  “CASEability”  of  Projects 

5.1  Theme  Description 

This  workshop  session  examined  a  range  of  characteristics  of  a  software  development  project, 
including  process  factors  that  are  positive  and  negative  indicators  that  a  CASE  tool  can  be 
successfully  employed  and  bring  beneficial  results  to  the  project. 

5.2  Goal 

The  goals  of  this  workshop  session  were  twofold: 

1.  Identification  of  what  attributes  of  a  software  development  project  are 
essential  to  introduce  CASE  or  (if  already  begun)  to  accelerate  CASE 
adoption. 

2.  Identification  and  recommendations  of  actions  needed  to  create  these 
essential  project  attributes. 

5.3  Process 

To  accomplish  the  goals  of  this  workshop  session,  the  following  brainstorming  approach  was 
employed: 

1 .  nominate  attributes 

2.  debate,  agglomerate 

3.  rank  attributes 

4.  nominate  recommendations 

5.  debate,  agglomerate 

6.  rank  recommendations 

7.  review  of  other  issues,  rebrainstorm,  debate,  rank 

Nominations  were  made  using  a  simple  round-robin  process.  The  floor  was  closed  for  new 
nominations  either  when  time  expired,  or  when  there  were  eight  passes  (equal  the  number  of 
workshop  participants)  in  a  row. 

Workshop  participants  voted  on  attributes.  Each  participant  was  allotted  a  fixed  number  of 
votes  (equal  to  1/3  the  number  of  items  to  be  ranked)  which  could  be  allocated  to  a  maximum 
of  2  votes  per  attribute.  The  attributes  with  the  most  votes  were  considered  the  most  important 
problem  areas  and  resolutions  to  these  problems  were  sought  using  the  same  brainstorming, 
voting,  and  ranking  method. 
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5.4  Attributes 


From  the  initial  nomination  step,  76  attributes  were  identified.  (See  Appendix  C.1  for  this  com¬ 
plete  list.) 

5.5  Classification 

A  rudimentary  classification  scheme  was  proposed  to  identify  clusters  of  related  attributes. 
This  classification  scheme  originally  consisted  of  the  following  classes,  with  their  associated 
attributes.  Attributes  could  appear  in  more  than  one  class. 

•  Pre-conditions 

•  Change  Process/Management 

•  Implementation  Phase  -  Tool 

•  Implementation  Phase  -  Process/Feedback 

•  Implementation  Phase  -  People 

•  Economics  (discussion  and  further  consideration  of  economic  issues  were 
tabled  in  view  of  the  concurrent  cost  estimation  session) 

•  Other 

(For  a  complete  cross  reference  of  attributes  and  their  related  class  assignment,  subsequent 
agglomeration,  and  voting,  see  Appendices  C.2,  C.3,  and  C.4.) 

5.5.1  Top  Attributes 

Summarized  below  are  the  final  ‘lop  13”  attributes  from  this  session.  These  attributes  have  the 
most  significant  bearing  on  the  potential  success  of  using  CASE  on  a  particular  project: 

•  Pre-conditions 

1 .  commitment  to  training  and  education. 

2.  acceptance  of  CASE  tools  by  development  team. 

3.  room  for  failure;  plan  for  success;  mitigate  risk  (freedom  from  worth 
of  CASE  tools). 

4.  sufficient  lead  time  and  resources  committed  plus  adequate 
schedule. 

5.  customer  reinforcement  (the  government  must  have  leverage  to 
reinforce  the  use  of  CASE). 

6.  commitment  to  well-defined  standards  and  procedures. 
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•  Change  Process/Management 

7.  champion  with  stature  (clout). 

8.  management  mandate  for  tool  usage  and  its  products. 

9.  identification  of  and  commitment  to  incentives  for  CASE  adoption, 
plus  rewards  for/recognition  of  success. 


•  Implementation  Phase  -  Tool 

10.  organizational  and  technical  support  for  needed  future  abstractions 
and  methods  for  reuse,  maintainability,  auto-documentation,  auto¬ 
design,  integration  of  software  packages,  reengineering,  etc. 

•  Implementation  Phase  -  Process/Feedback 

11.  metric/measurement  program  in  place  plus  feedback  loop  for 
improvements  and  lessons  learned. 

12.  establishment  of  a  dedicated  tools/methods/process  group. 

•  Other 

13.  SEI  assessment  program  (similar  to  the  Process  Assessment 
program)  for  maturity  of  tool  users  and  vendors. 

5.6  Recommendations 

Recommendations  were  “brainstormed”  using  the  same  nomination  process  used  for  identify¬ 
ing  attributes.  One  constraint,  however,  was  that  recommendations  had  to  satisfy  (i.e.,  be 
traceable  to)  attributes  that  received  5  or  more  votes.  From  the  initial  recommendations  step, 
33  recommendations  were  tallied,  grouped,  traced,  and  voted  upon.  (See  Appendix  C.5  for 
this  complete  list.) 

5.6.1  Top  Recommendations 

Summarized  below  are  the  final  Top  13"  recommendations  from  this  session.  When  imple¬ 
mented,  these  recommendations  will  do  the  most  to  ensure  the  potential  success  of  using 
CASE  on  a  particular  project: 

•  Develop  a  plan  for  CASE  Adoption  which  includes:  establishment  of  project 
standards  and  procedures,  training  in  tools  and  methods,  tool  selection, 
installation,  and  customization. 

•  Create  a  metrics  program  to  provide  feedback  for  process  evaluation  and 
continuous  improvement. 

•  Establish  a  dedicated  process,  methods,  and  tools  group. 

•  Establish  a  management  mandate  for  automated  process,  methods,  and 
tools  (i.e.,  CASE  Adoption). 
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•  Select  CASE  tools  that  are  extensible  and  open  to  provide  for  future 
methods,  abstractions,  reuse,  maintainability,  etc.,  to  avoid  obsolescence. 

•  Modify  MIL  STD  DIDS  (e.g.,  SD,  CM  QA  Plans)  to  focus  on  methods  and 
plans  for  CASE  utilization. 

•  Cause  corporate  leadership  (CEO  or  equivalent)  to  designate  a  VPGM  (or 
other  with  “clout")  to  be  the  CASE  adoption  leader  with  a  mandate  for  action. 

•  Establish  or  join  CASE  adoption  societies  (internal  or  external)  for  mutual 
support,  standardization,  and  knowledge-acquisition. 

•  Identify  incentives  and  rewards  (e.g.,  cash  bonuses)  for  CASE  adoption, 
creating  reusable  components,  and  implementing  new  technologies. 

•  Create  a  risk  reduction  program/guidelines  for  mitigating  risk  in  the  CASE 
adoption  process. 

•  Establish  a  plan  for  up-front  and  continued  training  and  incentives  for  CASE 
tools. 

•  Provide  adequate  schedule  flexibility  for  CASE  adoption  in  the  procurement 
process  to  ensure  adequate  lead  time  and  resource  availability. 

•  Establish  a  CASE  tools  usage  database  to  provide  CASE  user  community 
with  lessons  learned. 

5.6.2  Recommendations  for  the  SEI 

During  brainstorming,  several  recommendations  were  made  which  translated  into  calls  for  SEI 
action.  Although  none  of  these  recommendations  accumulated  sufficient  votes  to  qualify  as  a 
top-rated  recommendation,  the  workshop  participants  nevertheless  decided  to  call  special  at¬ 
tention  to  the  recommendations.  These  SEI-related  recommendations  were: 

•  Modify  the  SEI  Process  Assessment  program  to  include  two  new  scalars 
(tools  and  metrics)  with  an  eye  on  the  future  addition  of  other  scalars  (to 
motivate  CASE  adoption). 

•  The  SEI  should  author,  distribute,  and  provide  training  for  a  CASE 
evaluation  process  to  enable  tool  users  and  DoD  to  select  CASE  versus 
requirements. 

•  Form  an  SEI-sponsored  CASE  adoption  SWAT  team. 

•  Create  a  follow-up  session  to  allow  the  group  to  focus  on  specific  items  like 
a  CASE  Adoption  Plan. 

5.7  Session  Review 

Only  one  issue  of  consequence  was  brought  up  during  the  review  session.  The  session  leader, 
Dr.  Royce,  wanted  to  emphasize  that  the  current  C-language  orientation  of  CASE  was  a  strong 
inhibitor  to  CASE  adoption  and  evolution;  he  said  that  C  is  too  low-level,  and  does  not  support 
abstraction  to  the  degree  to  which,  for  example,  C++  and  Ada  do.  He  said  that  he  was  not 
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advocating  Ada  or  C++  in  particular,  but  was  merely  arguing  that  a  migration  from  C-ievel  se¬ 
mantics  to  a  high-order  language  would  be  extremely  helpful. 

5.8  Conclusion 

Participants  in  this  session  noted  that  preconditions  and  management  factors  far  outweighed 
technical  and  tool  issues  as  key  factors  that  are  most  likely  to  affect  the  successful  outcome 
of  using  CASE  on  a  particular  project.  While  no  "silver  bullets”  were  uncovered,  the  session 
did  help  participants  identify  a  number  of  areas  in  which  more  work  is  required. 
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6  Developing  a  Realistic  Budget  for  CASE  Tool 
Adoption 

6.1  Theme  Description 

This  session  focused  on  the  issue  of  providing  a  realistic  cost  estimate  for  CASE  tool  adoption. 

There  are  two  key  motivators  for  this  workshop  session: 

1.  Would-be  CASE  implementors  too  often  mistakenly  focus  only  on  the 
acquisition  cost  of  a  CASE  tool.  Over  the  course  of  a  CASE  tool  adoption, 
implementors  may  discover  that  CASE  adoption  costs  are  analogous  to  an 
iceberg.  Just  as  the  visible  tip  of  an  iceberg  represents  only  1/5  to  1/7  of  its 
true  size,  the  vendor’s  price  of  a  CASE  tool  represents  only  a  small  portion 
of  the  total  adoption  cost  of  CASE.  In  addition  to  acquisition  costs,  CASE 
adoption  can  include  significant  people  and  time  resource  costs. 

2.  There  is  a  critical  need  to  inform  corporate  management  about  the 
expected  costs  of  CASE  adoption.  This  is  an  essential  element  in 
managing  corporate  expectations. 


6.2  Goal 

To  address  these  issues,  the  initial  goal  of  this  workshop  session  was  to  discuss  various  cost 
components  and  prepare  a  framework  for  cost  estimation  to  aid  others  in  preparing  their  de¬ 
tailed  CASE  budgets.  The  framework  discussed  during  the  workshop  attempted  to  address 
the  following  aspects: 

•  The  cost  line  items  that  need  to  be  taken  into  account.  These  costs  include 
personnel,  technology  and  other  resources  that  must  be  estimated  and 
budgeted  for. 

•  The  actions  required  by  an  organization  to  assimilate  the  CASE  tool 
successfully,  and  their  associated  cost.  These  actions— training,  modifying 
technology  platforms,  implementing  new  methods  and  standards— depend 
on  the  organization's  readiness  to  adopt  the  CASE  tool. 

•  The  strategies  available  for  implementation.  Different  strategies— gradual 
introduction,  aggressive  adoption,  etc.— will  have  different  impacts  on  the 
timing  of  costs. 

6.3  Session  Introduction 

The  session  leader,  Mr.  Gonzalo  Verdugo  of  Rubin  Associates,  began  the  discussion  with  an 
overview.  His  presentation  included  an  examination  of  practical  framework  components,  a  de¬ 
scription  of  three  useful  frameworks,  and  several  CASE  implementation  scenarios.  Mr.  Ver¬ 
dugo  reviewed  several  measures  of  organizational  readiness  and  reviewed  the  SEI's  Software 
Process  Maturity  Framework  [22]  and  [11].  Finally,  his  presentation  provided  some  raw  cost 
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data  from  several  sources  such  as  [26],  [13],  [23],  and  a  STARS-sponsored  Hughes  Initial  and 
Operating  CASE  Investment  Model. 

6.4  Session  Mission  Statement 

In  the  course  of  session  discussion,  the  following  mission  statement  was  agreed  upon: 

Establish  a  framework/model  for  detailed  CASE  estimate  preparation  and  related  is¬ 
sues.  The  framework  should  include  guidelines  in  determining  the  appropriate  amounts 
of  people,  time,  and  dollar  resources  for  multiple  projects  under  a  single  organization 
for  CASE  tool  implementation. 

6.5  Results 

There  were  three  main  products  from  this  session.  First,  there  was  a  partial  list  of  issues  aimed 
at  promoting  topics  that  should  be  considered  in  the  economics  of  CASE  adoption.  The  gen¬ 
eral  topics  into  which  these  issues  fit  were: 

•  Process 

•  Management 

•  Economics 

•  Organizational 

•  Technology 

•  Standards 

•  Implementation 

The  second  major  product  was  a  pair  of  tables: 

•  CASE  Adoption  Life  Cycle  Estimate  Matrix 

•  CASE  Adoption  Principle  Cost  Estimate  Matrix 

These  two  tables  provide  a  quick  overview  of  the  major  factors  that  affect  the  economics  of 
CASE  adoption.  In  addition,  they  attempt  to  highlight  those  elements  that  are  primary  cost  driv¬ 
ers. 

The  third  product  was  an  action  plan  for  further  investigation  and  refinement  of  this  preliminary 
CASE  Adoption  Economic  Model. 

6.5.1  CASE  Adoption  issues 

Below  is  a  partial  list  of  issues  pertinent  to  the  economics  of  CASE  adoption: 

6.5.1. 1  Process 

•  Does  the  CASE  technology  you  are  implementing  match  your  process? 
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•  Are  you  buying  a  process  with  the  CASE  tool? 

•  Have  you  defined  your  software  development  process  before  automating  it? 

•  Is  there  :n*eraction  with  other  processes  (i.e.,  Systems  Engineering)? 

•  How  dc  „  j  get  to  a  certain  level  of  process  maturity  to  implement  CASE? 
Is  this  level  necessarily  level  3? 

6.5.1 .2  Management 

•  What  is  the  rationale  for  adopting  CASE? 

•  What  are  the  CASE  adoption  alternatives? 

•  What  is  an  affordable  CASE  adoption  strategy? 

•  How  do  you  design  a  CASE  adoption  strategy  to  support  an  organizational 
or  project  mission  and  strategy? 

•  How  do  you  identify,  measure,  and  harvest  the  actual  benefits  or 
opportunities  provided  by  CASE  adoption? 

6.5.1 .3  Economics 

•  What  is  the  cost  of  inaction? 

•  What  is  the  cost/benefit  of  action  and  how  do  you  maximize  return  on 
investment? 

•  How  is  CASE  adoption  funded? 

•  Is  there  the  potential  for  a  self-funding  strategy  (e.g.,  fee  for  service)? 

•  What  is  the  cost  of  tool  replacement? 

•  Have  you  considered  the  software,  hardware,  and  human  skill  elements  in 
your  costing  estimates? 

•  What  are  the  total  costs  of  a  software  upgrade?  (This  may  include  cost  items 
beyond  the  software  upgrade  itself,  such  as  a  corresponding  hardware 
upgrade.) 

•  Where  do  you  get  the  estimates?  Are  the  estimates  (e.g.,  training  estimates 
obtained  from  the  vendor)  valid?  Are  the  estimates  phase  related? 

6.5.14  Organizational 

•  How  do  you  build  top  level  understanding  and  commitment? 

•  How  do  you  set  appropriate  management  expectation? 

•  How  do  you  educate  top  management? 

•  How  does  the  organization  adapt  to  technology  introduction? 

•  How  do  you  manage  organizational  change? 

•  What  are  the  various  roles  and  responsibilities  in  the  organization? 
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•  How  does  this  fit  with  the  CASE  opportunity? 

6.5.1  .5  Technology 

•  What  is  the  technology  life  of: 

-software? 

-hardware? 

-human  skills? 

•  What  is  a  reasonable  timeframe  for  a  complete  technology  life  cycle? 

•  What  are  the  differences,  if  any,  in  CASE  implementation  in  various 
domains? 

-MIS  versus  engineering  and  real-time  CASE  domains 

•  What  are  the  differences  between  implementation  strategies? 

-distributed/centralized 

-platforms  focus  (mainframes/  workstations/  personal  computers), 
-organizational-wide/project-oriented 

•  Is  there  a  need  and/or  desire  for  suite  of  compatible  tools? 

6.5.1 .6  Standards 

•  What  is  the  cost  of  adopting  or  not  adopting  standards? 

•  What  level  of  standards  is  appropriate? 

-tools 

-interfaces 

-methodolog  ies/processes 

-reusable  code 
6J.1.7  Implementation 

•  How  does  the  organization  adapt  to  technology  introduction? 

•  How  do  you  manage  organizational  change? 

•  What  are  the  various  roles  and  responsibilities  in  the  organization? 

•  How  does  this  fit  with  the  CASE  opportunity? 

•  What  are  the  CASE  adoption  alternatives? 

•  without  top-level  commitment 

•  new  starts  versus  ongoing  project/evolution 
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•  How  effective  are  different  adoption  scenarios? 

•  Are  you  in  an  adoption  mode  without  top-level  commitment? 

6.5.2  CASE  Adoption  Estimation  Matrixes 

The  following  two  tables  provide  a  quick  overview  of  the  major  factors  that  affect  economic 
considerations  of  CASE  adoption.  In  addition,  they  highlight  those  elements  that  are  primary 
cost  drivers.  The  CASE  Adoption  Life  Cycle  Estimate  Matrix  table  is  organized  by  Life  Cycle 
Phases  (Analysis,  Acquisition,  Implementation  and  Operations)  and  HiTOP  categories  (Tech¬ 
nical,  Organization  and  People,  plus  an  additional  Management  category).  The  HiTOP  cate¬ 
gories  were  adopted  from  the  workshop  keynote  address  by  Dr.  Morell  of  the  Industrial  Tech¬ 
nology  Institute.  Overall,  these  tables  are  designed  to  motivate  potential  planners  to  consider 
a  wide  range  of  factors  that  can  influence  the  cost  of  CASE  Adoption. 
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categories 

Mgt  People  Organization  Technical 


CASE  Adoption  Life  Cycle  Estimate  Matrix 


Analysis 

Acauisition 

Implementation 

Operations 

Assessment 

-  Technology 

-  State  of  Practice 
•  Needs 

Establish  Requirements 
Architecture  Definition 

Selection 

-  Vendor/Tool 

-  Tool  Integ.  Strategy 

Purchase 

-  Negotiations 

-  Strategy 

-  TOOlS 

Infrastructure 

-  Network 

-  Mainframe 

-  Workstations 

Installation 

-  Site  Preparation 

Technical 

-  Tool  Integration 

Metrics  Analysis 

Testing 

-  Pilot 

Infrastructure  Support 

Maint.  &  Operations 

-  Re-Occurring  Costs 
-  License  Fees 

--  Personnel 
--  Facilities 

-  Infrastructure  Spt 
•  Version  Update 

Technology  Infusion 

Reassessment 

m 

Amllyslls  Pities® 

Assessment 

-  Process 

-  Culture 

Cultural  Change  Mgt 

Practices 

-  Q/A  &  Conf  Mgt 

-  New/Revised 

-  Documentation 
Cultural  Change  Mgt 

-  User's  Groups 

Practices 

-  Q/A  &  Conf  Mgt 

-  New/Revised 

-  Documentation 

Cultural  Change  Mgt 

-  User's  Groups 

Assessment 

-  Skills 

Skills  Development 

-  Implementors 

-  Users 

Skills  Development 

-  Training/Education 

-  Coaching 

-  Hiring 

Skills  Maintenance 

Committment  Building 
Monitoring 

Committment  Maint. 
Monitoring 

Committment  Maint. 
Monitoring 

Metrics  Review 

Committment  Maint. 
Monitoring 

Metrics  Review 

Table  2  CASE  Adoption  Life  Cycle  Estimate  Matrix 
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Main  Cost  Items 


Analysis 


Purchase 

-Tools 

-  Infrastructure 

•  Network 

Installation  *■ 
Skills  Deyelooment 


Technical/Tool  Integr. 

Practices 

Skills 

Testinq/Pilot _ 


Maint.  &  Operations 

-  Re-Occurring  Costs 

-  Infrastructure  Support 

-  Version  Updates 
Tech.  &  Practice  Updates 
Monitoring/Metrics 

Skills  Maintenance _ 


Staff  Turnover 


Key  Assumption: 

There  is  a  commitment  to  change  from  management  and  target  users. 


Table  3  CASE  Adoption  Principle  Cost  Estimate  Matrix 

6.6  Next  Steps 

Additional  work  is  necessary  to  achieve  our  original  mission  objectives  completely.  We  need 
to  complete  the  design  of  our  cost  model.  In  doing  so,  we  need  to  address  the  pertinent  issues 
raised  in  this  workshop  session.  These  include  development  of  rules  of  thumb  and  algorithms 
for  estimation.  We  hope  that  we  can  develop  a  set  of  estimation  algorithms  structured  in  a 
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manner  like  the  COCOMO  software  cost  estimate  model  [2].  We  should  also  develop  a  guide 
book  for  the  estimation  process.  Next,  a  number  of  case  studies  should  be  done  to  verify  the 
accuracy  of  the  model.  And  finally,  the  model  should  be  made  available  for  use  in  a  trial  period 
during  which  important  feedback  and  lessons  learned  can  be  incorporated  into  the  model. 

6.7  Conclusion 

The  material  included  in  this  section  provides  essential  information  to  those  who  must  prepare 
composite  estimates  for  implementing  CASE  in  their  organization.  It  provides  a  high-end 
framework  that  serves  as  a  checklist  of  elements  to  consider  when  developing  an  organiza¬ 
tion-specific  cost  estimate.  As  described  above,  the  next  step  in  this  process  is  the  develop¬ 
ment  of  an  algorithmic  cost  model  to  aid  in  the  CASE  adoption  estimation  process. 

In  addition  to  this  high-end  framework,  there  still  is  an  important  need  for  detailed  information 
about  specific  tools  and  vendors.  Those  who  have  this  need  may  refer  to  Appendix  D,  CASE 
Resource  Pointers.  In  this  appendix,  there  are  8  tables  that  provide  a  useful  set  of  pointers  to 
different  sources  of  information  on  CASE  tools.  While  not  all-inclusive,  this  information  exem¬ 
plifies  the  type  of  information  that  is  available  from  commercial  and  government  sectors. 
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7  Making  the  CASE  Tool  Fit  the  Organization  and 
the  Organization  Fit  the  Tool 

7.1  Theme  Description 

All  organizations  have  difficulty  coping  with  change.  This  concept  certainly  applies  to  a  com¬ 
pany's  decision  to  incorporate  CASE.  The  focus  of  this  workshop  session  was  to  examine 
some  of  the  changes  that  an  organization  may  need  to  make  if  tool  adoption  is  to  be  success¬ 
ful,  and  to  identify  the  modifications  that  may  be  required  of  tools  and  tool  vendors. 

7.2  Goal 

The  goal  of  this  workshop  session  was  to  identify  tool  and  organizational  characteristics  that 
facilitate  or  inhibit  CASE  adoption. 

7.3  Discussion  Topics 

In  pursuit  of  this  goal,  the  subsequent  discussion  focused  on  four  topic  areas: 

1 .  Tool  characteristics  that  facilitate  CASE  adoption 

•  Customizable 

•  Integratable 

•  Vendor  support 

•  Extensibility 

•  Documentation 

•  Platform  independence 

2.  Tool  characteristics  that  inhibit  CASE  adoption 

•  Failure  to  adopt  industry  trends 

•  Poor  performance 

•  Tool  proprietary  methodologies 

•  Single-user  versus  multi-user  tools 

3.  Organizational  characteristics  that  facilitate  CASE  adoption 

•  Defined/understood  processes  and  standards 

•  Training 

•  Communication 

•  Management  support  for  implementation 

•  Ongoing  support 

4.  Organizational  characteristics  that  inhibit  CASE  adoption 

•  Cost 
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•  Maintenance  versus  new  development 

•  Heterogeneous  development  environment 

Each  topic  was  discussed  in  terms  of  the  following  factors  (as  applicable): 

•  Definition 

•  Examples 

•  How  to  implement 

•  Risks 

7.4  Tool  Characteristics  That  Facilitate  CASE  Adoption 

7.4.1  Customizable 

Definition:  Ability  to  tailor  the  tool's  features  and  functions  to  the  organization’s  needs. 
Examples: 

•  Report  contents  and  formats. 

•  User-defined  symbols  and  checking  rules. 

•  Ability  to  respond  to  changes  in  the  work  flow  (e.g.,  tool  that  will  allow  you 
to  “check  in"  a  diagram  that  is  not  semantically  correct). 

•  Ability  to  facilitate  the  production  of  documentation. 

How  to  Implement: 

•  Customization  may  be  done  by: 

•  group 

•  company 

•  project 

•  user-by-user 

•  centralized 

•  through  a  clearing  house 

There  should  be  an  entity  responsible  for  customization 

Maintenance  of  versions  of  customized  tools  and  environments 

Providing  inadequate  support  of  the  process  of  customization. 

Not  fully  understanding  the  complexity  of  customization. 

Customization  may  violate  a  tool-enforced  standard. 

Customization  may  sacrifice  a  feature  of  a  tool  (e.g.,  can’t  use 
consistency  checking  features  if  you've  redefined  what  a  symbol  means 


Risks: 
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in  a  diagrammatic  tool). 


7.4.2  Integratable 

Definition:  Information  captured  by  one  tool  accessible  to  other  tools  in  Software  Develop¬ 
ment  Environment  (SDE);  ability  to  initiate  and  accept  information  from  other  tools  in  SDE. 

Examples: 

•  EIA  CDIF  CASE  data  interchange 

•  Message  passing— Softbench  Message  Server 

•  Linking — Sun’s  link  services 

How  to  Implement: 

•  Many  models — outside  the  scope  of  this  workshop. 

Risks: 

•  Too  much  faith  in  immature  technology. 

•  Demonstrated  only  for  programming  in  the  small;  questionable  scalability. 

•  Semantic  integration — two  tools  tightly  coupled  act  as  third  tool,  with 
indeterminate  characteristics. 

7.4.3  Vendor  Support 

Definition:  Quality  training,  timely  technical  support,  user  groups,  support  for  customization, 
mechanisms  for  accepting  inputs  on  enhancements  or  bugs;  provided  by  vendor. 

How  to  Implement: 

•  Get  an  evaluation  copy  of  tool 

•  Get  an  evaluation  copy  of  documentation 

•  Attend  vendor  training 

•  Attend  user  group  meetings 

7.4.4  Extensibility 

Definition:  Adding  functionality  and  value  to  the  tool;  goes  beyond  customization. 

7.4.5  Documentation 

Examples:  User  manual,  reference  manual,  tutorial,  on-line  help,  meaningful  diagnostics, 
master  index,  reference  card,  supplementary  texts  (for  supported  methods). 

Risks: 

•  Not  enough  documentation. 

•  Not  clear  enough  for  user  to  learn  basics  of  tool  quickly. 

•  Potential  "shelf-ware.” 
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•  Updates/change  pages  do  not  occur  with  tool  upgrades. 

7.4.6  Platform  Independence 

Definition:  Tool  has  ability  to  share  information  and  control  across  platforms  (interoperability). 
Tool  operates  on  a  variety  of  platforms. 

Examples: 

•  X-windows,  NFS  (hide  platform  variations) 

How  to  Implement: 

•  Tool  makes  use  of  X-window  interface,  or  is  able  to  reside  on  NFS 

Risks: 

•  Buying  into  a  proprietary  solution 

7.5  Tool  Characteristics  that  Inhibit  Adoption 

7.5.1  Failure  to  Adopt  Industry  Trends 
Examples: 

•  Tool  linked  to  obsolete/restricted  platforms  and  environments. 

•  Tool  can’t  accommodate  evolving  methods. 

Risks: 

•  Not  tracking  standards  and  trends  diminishes  tool’s  ability  to  interoperate, 
integrate,  and  be  portable. 

7.5.2  Poor  Performance  (of  Tool) 

How  to  Implement: 

•  Plan/manage  project  growth 

•  Recognize  requirements  (tool,  platform,  software) 

Risks: 

•  Productivity 

•  Scalability 

•  Frustration — tool  so  slow  to  use,  all  CASE  use  is  terminated 

7.5.3  Tool  Proprietary  Methodologies 
Risks: 

•  Training  &  literature  may  not  be  readily  accessible. 

•  Client  does  not  readily  accept. 

•  Evolution  is  restricted. 


60 


CMU/SEI-91-TR-14 


•  Customer  may  be  locked  in  to  one  vendor’s  tool  and/or  methodology. 

•  Tool  proprietary  methodologies  may  not  ever  be  a  de  facto  or  official 
standard. 

•  Tool  can't  be  re-used  or  shared. 

7.5.4  Single-User  Versus  Multi-User 

Definition:  Stand-alone  versus  cooperative  environment  (real  time). 

Risks: 

•  Single  user —  isolation,  inadequate  CPU  and  disk  resources. 

•  Multiple  user— security  and  configuration  management;  inadequate 
network  resources,  cpu,  disk,  etc. 

•  Both — performance,  scalability,  availability. 

7.6  Organizational  Characteristics  That  Facilitate  CASE  Adoption 

7.6.1  Defined/Understood  Processes  and  Standards 
Examples: 

•  21 67/21 67A 

•  Home-brewed  cookbook  (site-specific) 

•  Folklore  or  company  culture 

•  Company  proprietary 
How  to  Implement: 

•  Marry  tool  with  process  (nontrivial  &  generally  underestimated). 

Risks: 

•  Conflict  between  tool  and  organization  structure  and  process. 

•  Reliance  on  tool  to  set  the  process — may  be  beyond  tool’s  capabilities. 

•  Potential  to  buy  wrong  tool  set. 

•  Inconsistent  tool  use  (example:  two  people  using  same  tool,  yet  using 
completely  different  naming  conventions — tool  can’t  enforce  a  naming 
convention!). 

7.6.2  Training 

Definition:  Training  in  methods,  tool,  and  customization 

Examples: 

•  Hands-on  training  (very  important) 

•  On-line  training 

•  Training  assistance  from  in-house  "centers  of  excellence” 
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How  to  Implement: 

•  In-house  support  capability 

•  Consistent  vendor-supplied  training 

•  Provided  for  consultants,  new  hires,  etc. 

Risks: 

•  Misuse  and  inconsistency. 

•  Insufficient  frequency  and/or  timeliness  (too  soon,  too  late,  not  often 
enough  for  all  employees). 

•  Irrelevance — the  examples  in  the  training  sessions  are  far  removed  from 
the  user’s  domain 

•  User  frustration. 

•  Unrealistic  expectations— training  can’t  make  a  person  an  expert. 

7.6.3  Communication 
Examples: 

•  Promote  between  champions  and  coaches 

•  “Sign-off”  &  buy-in  from  all  relevant  groups  (QA  agrees  in  tool’s 
representation,  CM  agrees  tool’s  objects  will  be  stored,  etc.);  connect  with 
the  multiple  disciplines  involved  in  managing  project  (QA,  CM,  etc.) 

•  Pass  lessons  learned  to  future  projects. 

•  Use  electronic  bulletin  boards. 

•  Use  tool  itself  to  support  structured  communication — through  project 
management,  conferencing,  notes,  on-line  (extensible)  documentation. 

Risks: 

•  Champion  with  hidden  agenda. 

•  Chaos. 

•  Excessive  or  overly  formal  communication. 

•  Lack  of  focus  (e.g.,  1 8  different  newsletters  for  one  division,  no  one  reads 
them). 

•  False  perceptions. 

•  Communication  clouded  by  politics — newsletters  seen  by  customer 
contain  only  “happy  talk." 

•  “Filters”  for  communications. 

•  "Blinders” — people  don’t  avail  themselves  of  communication  mechanisms 
available. 

7.6.4  Management  Support  for  Implementation 
How  to  Implement: 
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•  Sanction  and  support  for  pilot  projects. 

•  Accommodation—  $$$$  (funding  available  for  purchase). 

•  Planning,  schedules,  and  ancillary  development. 

•  New  infrastructure. 

Risks: 

•  Mandate  without  buy-in  at  lower  levels  (can’t  get  developers  to  use). 

•  Grassroots  movement  without  management  support. 

•  Politics  &  self-fulfilling  prophecies  (you  can  try  it,  but  it  won’t  help  you 
anyway). 

•  Lack  of  interdepartmental  buy-in/support. 

•  Poor  planning  of  time  &  resources. 

•  External  customer  perspectives — customer  should  understand  the  actual 
cost  and  schedule  impacts  of  CASE  adoption;  customer  should  not 
expect  CASE  to  revolutionize  the  organization,  but  to  impact  the 
organization  in  an  evolutionary  way. 

7.6.5  Ongoing  Support 
How  to  Implement: 

•  Maintenance — track  evolution  in  tools  and  process. 

•  System  administration  of  tool — install  upgrades. 

•  Continue  training. 

•  Use  coaches. 

•  Provide  feedback  loop  for  future  uses  of  tool. 

Risks: 

•  Tool  becomes  obsolete. 

•  Misuse — user  expertise  lags  behind  tool/technical  capabilities. 

•  Compatibility — different  versions  of  same  tool;  can’t  share  data,  versions 
get  out  of  synch. 

7.7  Organizational  Characteristics  That  Inhibit  Adoption 

7.7.1  Cost 

•  Deferring  to  “Developing  a  Realistic  Budget  for  CASE  Tool  Adoption” 
session. 

7.7.2  Maintenance  Versus  New  Development 
Risks: 

•  CASE  not  always  applicable  to  existing  system  (maintenance). 
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•  Reliance  on  “reverse  engineering  will  solve  our  problems”  (new 
development). 

•  CASE  tools  aren’t  used  early  enough  to  capture  information. 

•  The  state  of  design  automation  is  not  recognized — different  types  of 
design. 

•  Although  “reengineering"  techniques  have  been  around  since  the  70’s, 
automation  isn't  available  for  it  yet. 

7.7.3  Heterogeneous  Development  Environment 

Definition:  Tool  and  platform  choices  may  be  restricted  to  what  has  currently  been  purchased 
by  the  organization. 

Examples: 

•  Many  machines 

•  Operating  systems  (VMS,  OS/2,  UNIX,  etc.) 

•  Graphical  user  interfaces  (OSF/Motif,  OpenLook,  Present  Manager,  etc.) 

•  Networks  (NFS,  DECNET,  PCNET,  etc.) 

How  to  Implement: 

•  The  trend  is  towards  heterogeneous  development  environment  (what 
vendor  is  selling  the  least  expensive  box  this  month). 

Risks: 

•  Prediction  of  future  environments  and  technology  is  difficult. 

•  Tool  vendors  aren’t  tracking  trends. 

•  Users  are  required  to  know  many  different  systems. 
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Appendix  B  Workshop  Session  Assignments 

B.1  Adoption  Roles  and  the  Adoption  Life  Cycle  for  CASE 

Session  Leaders 
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John  Maher,  Software  Engineering  Institute 
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Ed  Morris,  Software  Engineering  Institute 

Scribe 

Joseph  Morin,  Software  Engineering  Institute 
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Odean  Bowler,  Air  Force  Software  Technology  Support  Center 
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Roy  B.  Levow,  Florida  Atlantic  University 
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B.2  Can  You  Get  the  Benefits  of  CASE  Without  Buying? 

Session  Leader 
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Paul  Zarrella,  Software  Engineering  Institute 

Scribe 
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Jim  Hager,  HRB  Systems,  Inc. 
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Scribe 
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B.4  The  CASEability  of  Projects 
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Win  Royce,  TRW 

CASE  Project  Member 
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Scribe 
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Scribe 
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Participants 
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C.1  Complete  Attributes  List  from  Initial  Brainstorm 

1 .  Acceptance  by  development  team . 

2.  Real  demand  for  the  tool  (development  team  has  a  need  for  the  tool). 

3.  Establish  successful  processes  prior  to  tool  selection  (vs.  opposite). 

4.  Strong  management  commitment. 

5.  Clear  objectives  for  quality  and  productivity  improvement. 

6.  General  structured  methodology  acceptance  (not  necessarily  structured 
analysis,  but  any  general  methodology). 

7.  Room  for  failure;  plan  for  success;  mitigate  risk  (freedom  from  worth  of 
CASE  tools). 

8.  Neutralizing  “not  invented  here." 

9.  Tool  cohesion  (the  way  tools  interact  with  each  other). 

1 0.  Customer  reinforcement  (the  government  must  have  leverage  to  reinforce 
the  use  of  CASE). 

1 1 .  Enumerated/documents  requirements  for  CASEability  of  the  project. 

12.  Champion  with  stature  (clout). 

13.  Desire  and  motivation  for  change. 

14.  Commitment  to  training  and  education. 

15.  Cultural  change  experts  (to  help  with  the  change  process  vs.  technical 
issues). 

16.  Guaranteed  tool  maintenance,  e.g.,  vendor  viability. 

17.  Real  solution  to  the  environment  evolution  problem — impact  of  tool 
evolution  on  environment. 

18.  Tool  that  provides  control  and  productivity  gains. 

19.  Plan  to  mitigate  probability  of  failure  to  0%. 

20.  Sufficient  lead  time  and  resources  committed  plus  adequate  schedule. 

21 .  Capturing  and  storing  lessons  learned. 

22.  Feedback  loop  for  improvements  and  lessons  learned. 

23.  Real  cost  estimation  and  ROI  (return  on  investment)  justification 
(tool/process/implementation). 

24.  Adequate  schedule  and  management  attention  to  keep  schedule 
adequate. 
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25.  Metric/measurement  program  in  place  plus  feedback  loop  for 
improvements  and  lessons  learned. 

26.  Commitment  to  well-defined  standards  and  procedures. 

27.  Reward  and  recognize  success. 

28.  Commitment  to  developing  in-house  tools  to  help  with  integration  of  tools. 

29.  Commitment  to  spending  time  studying  environment. 

30.  Openness  to  COTS/NDI  (commercial  off-the-sheif/non-deveiopmentai 
items). 

31 .  Flexibility  to  absorb  new  unforeseen  developments  (integrate  change). 

32.  Viable  measure  of  tool  quality  (i.e.,  CASE  consumer  reports). 

33.  Manager  mindset  change  from  hardware  to  software  orientation. 

34.  Support  organization  impacted  accounted  for  (e.g.,  CM  (Configuration 
Management),  data,  QA  (Quality  Assurance),  training) 

35.  Availability  of/access  to  CASE  experts. 

36.  Staffed  process  group. 

37.  Commitment  from  tool  vendors  to  incorporate  user  feedback. 

38.  Organizational  and  technical  support  tor  needed  future  abstractions  and 
methods  for  reuse,  maintainability,  auto-documentation,  auto-design, 
integration  of  software  packages,  reengineering,  etc. 

39.  Tool  composability  (syntactic  and  semantic). 

40.  Flexibility  to  update  tool  for  new  methods  and  methodology  improvements. 

41 .  Adequate  hardware  platform  resources. 

42.  Skills/experience/attitude  of  technical  team. 

43.  Recognizing  the  difference  between  MIS  and  real-time  environments. 

44.  Openness/access  to  tool  vendor  code. 

45.  Monitoring  the  use  of  tools  by  QA  enforcement. 

46.  Multiple  access  paths  to  tool  features. 

47.  Financial  (i.e.,  longevity)  assurance  of  vendors. 

48.  Extent  of  the  cultural  change  of  the  organization. 

49.  Commitment  to  educate  customer/procurement  regarding  CASE 
technology. 

50.  Standard  interface  across  tools. 
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51 .  Nationwide  standardization  of  tool  control,  data  passing. 

52.  Management  mandate  for  tool  usage  and  its  products. 

53.  Proof  of  the  adoption  life-cycle. 

54.  Access  to  CASE  environments,  tools  evaluation  data  (consumer  union  for 
tools). 

55.  Overcome  “camcorder  syndrome"  (i.e.,  just  pick  a  tool,  don't  wait  for  all  the 
features). 

56.  Identification  of  and  commitment  to  incentives  for  CASE  adoption,  plus 
rewards  for/recognition  of  success. 

57.  Don’t  expect  it  to  be  easy. 

58.  How  to  create  incentive  for  tool  vendors  to  provide  tool  cohesion. 

59.  Tailorability  to  project  users. 

60.  Require  market  pressures  for  open  systems. 

61 .  Evaluate  more  than  the  software,  but  rather  the  quality  of  the  engineering 
attributes  (of  products). 

62.  Inject  academic  programs  with  the  CASE  notion. 

63.  Previous  experience  (of  developers)  with  CASE  tools/methods. 

64.  Get  the  government  to  stop  the  “paper  game.” 

65.  Why  does  the  DoD  think  they  have  to  invent  tools  and  environments? 

66.  Size,  complexity,  documentation  requirements  must  be  handled  by  CASE. 

67.  Sensitize  your  customer  or  investor  to  CASE  prior  to  'the  eleventh  hour.” 
(waiting  until  the  last  minute  when  it’s  too  late) 

68.  Establishment  of  a  dedicated  tools/methods/process  group. 

69.  Organizational  commitment  to  utilize  CASE  technology  for  re-engineering 
and  maintenance. 

70.  Set  organizational/customer  expectations  re.  productivity/quality  for  CASE 
use. 

71 .  Recognize  language  independence  for  most  CASE  situations. 

72.  Encourage  CASE  “skunkworks"  (projects  experimenting  on  their  own 
initiative). 

73.  SEI  assessment  program  for  tool  users  and  tool  vendors  for  their  maturity 
ala  the  process  assessment  program. 

74.  Dispel  job  loss  fears  from  the  adoption  of  CASE. 
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75.  Use  all  possible  communication  paths  to  sell  CASE. 

76.  Create  non  project-specific  learning  groups/skunkworks  to  investigate  the 
CASE  domain. 

C.2  Attribute  Classification 

A  rudimentary  classification  scheme  was  proposed  to  identify  clusters  of  related  attributes. 
This  classification  scheme  originally  consisted  of  the  following  classes,  with  their  associated 
attributes.  Attributes  can  appear  in  more  than  one  class. 


Pre-conditions: 


1 

2 

3 

4 

6 

7 

10 

13 

14 

19 

20 

24 

26 

48 

57 

Change  Process: 

8 

12 

13 

15 

33 

34 

35 

49 

52 

53 

55 

67 

69 

70 

72 

75 

76 

Implementation  Phase  -  Tool 

9 

11 

16 

17 

18 

28 

31 

32 

37 

38 

39 

40 

41 

43 

44 

46 

47 

50 

51 

54 

58 

59 

66 

71 

Implementation  Phase  •  Process/Feedback 

3 

5 

10 

21 

22 

24 

25 

26 

29 

32 

36 

45 

53 

54 

61 

68 

Implementation  Phase  -  People 

1 

27 

42 

63 

74 

Economics 

23 

41 

56 

66 

Other 

30 

50 

51 

58 

60 

62 

64 

65 

73 
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C.3  Attribute  Agglomeration 

Of  the  original  73  attributes,  several  were  merged.  In  the  following  merge  table,  the  leftmost 
attribute  number  indicates  the  main  attribute  into  which  other  attributes  have  been  merged. 


Main  Attribute 

Merge 

1 

8 

52 

4 

5 

70 

6 

19 

16 

47 

32 

54 

50 

51 

58 

9,39 

70 

5 

76 

72 

The  following  attributes  were  merged  or  removed  from  consideration  because  of  obvious  over¬ 
lap  with  other  attributes:  6,  21 ,  22,  23,  24,  27. 


C.4  Attribute  Voting 

The  following  table  summarizes  the  voting  on  the  attributes.  It  was  decided  by  acclamation  that 
those  attributes  receiving  fewer  than  5  votes  would  not  be  considered  further. 


Votes 


Attributes 


9 

8 

7 

5 

4 

3 

2 

1 


12,  14,  25,52,68 
38,56 

I. 7,  20, 

10,  26,  73 

2,  3,  30,  50,  70 
13,28,32,44,59,  66 

II,  17,  41,42,58 

16,  35,37,  46,48,  49,60,  75 
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C.5  Recommendation  from  Initial  Brainstorm 


1 .  Establish  a  dedicated  process,  methods,  and  tools  group. 

2.  Establish  a  management  mandate  for  automated  process,  methods,  and 
tools  (i.e.,  CASE  Adoption). 

3.  Create  a  risk  reduction  program/guidelines  for  mitigating  risk  in  the  CASE 
adoption  process. 

4.  Establish  a  plan  for  up-front  and  continued  training  and  incentives  for 
CASE  tools. 

5.  Educate  users  on  change  management. 

6.  Use  SEI  process  evaluation  to  motivate  CASE  Adoption. 

7.  Provide  adequate  schedule  flexibility  for  CASE  adoption  in  the 
procurement  process  to  ensure  adequate  lead  time,  resources,  budget  are 
applied  by  contractors. 

8.  Create  a  metrics  program  to  provide  feedback  for  process  evaluation  and 
continuous  improvement. 

9.  Develop  a  plan  for  CASE  Adoption  which  includes:  establishment  of 
project  standards  and  procedures,  training  in  tools  and  methods,  tool 
selection,  installation,  and  customization. 

10.  Modify  the  SEI  Process  Assessment  program  to  include  two  new  scalars 
(tools  and  metrics)  with  an  eye  on  the  future  addition  of  other  scalers  (to 
motivate  CASE  adoption). 

1 1 .  Create  rewards  program  related  to  CASE. 

12.  Write  CASE  Adoption  plan;  tie  CASE  Adoption  to  revenue  producing 
activities;  compute  ROI  goals. 

13.  Establish  a  CASE  Tools  usage  database  to  provide  CASE  user  community 
with  lessons  learned. 

14.  Government  contracts  and  program  management  should  support  CASE 
Adoption  and  use  throughout  the  lifecycle. 

15.  Modify  MIL  STD  DIDS  (e.g.,  SD,  CM  QA  Plans)  to  focus  on  methods  and 
plans  for  CASE  utilization. 

16.  Establish  data  standards  working  group  at  time  of  implementation. 

17.  Cause  corporate  leadership  (CEO  or  equivalent)  to  designate  a  VPGM  (or 
other  with  “clout")  to  be  the  CASE  adoption  leader  with  a  mandate  for 
action. 

18.  Suggest  to  tool  vendors:  provide  for  extensibility  to  provide  for  software 
reuse,  re-engineering,  and  maintenance. 
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19.  Consider  development  culture  as  an  important  aspect  of  tool  selection. 

20.  CASE  tools  must  be  extensible  and  open  io  provide  for  future  methods, 
abstractions,  reuse,  maintainability,  etc.,  to  avoid  obsolescence. 

21 .  Commit  to  up-front  costs  for  time  and  training  for  CASE  adoption. 

22.  Develop  a  plan  for  new  technology  insertion  to  allow  for  methods  and  tools 
enhancements  as  CASE  technology  evolves. 

23.  The  SEI  should  author,  distribute,  and  train  a  CASE  evaluation  process  to 
enable  tool  users  and  DoD  to  select  CASE  vs.  requirements. 

24.  Inform  development  team  on  what  will  change  and  not  change. 

25.  Use  a  CASE  Adoption  corporate  newsletter  to  build  the  team,  advance 
mandate,  et.  al. 

26.  Create  an  SEI-sponsored  CASE  adoption  SWAT  team. 

27.  Create  non-project-specific  related  CASE  working  groups. 

28.  Expect  to  help  projects  risking  first  usage  of  CASE;  motivate  them  by 
support  to  accept  some  risk  (e.g.,  through  contractual  mechanisms). 

29.  Create  ongoing  CASE  training  program  with  incentives  for  project 
involvement. 

30.  Identify  incentives  and  rewards  for  CASE  adoption  and  creating  reusable 
components  and  implementing  new  technologies  (e.g.,  cash  bonuses). 

31.  To  “jump-start”  CASE  experience  acquisition  offices  should  use  a  front- 
end  CASE  tool  to  generate  in  total  the  software  procurement  packages. 

32.  Contractor  organizations  should  use  a  front-end  CASE  tool  to  develop  a 
proposal  package  in  total. 

33.  Establish  or  join  CASE  adoption  societies  (internal  or  external)  for  mutual 
support,  standardization,  and  knowledge-acquisition. 


C.5.1  Recommendations  Agglomeration 


Main  Recommendation 
4 
9 
15 
20 
33 


Merge 


29 

12, 19,21,22 
14 
18 
27 


C.5.2  Recommendations  Traceability 

The  following  table  describes  the  traceability  of  recommendations  to  requirements. 
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Recommendation 


Attribute 


1 

68 

2 

52 

3 

7 

4 

14 

5 

1,14 

6 

12,  52 

7 

20 

8 

25 

9 

14,  26 

10 

12,  52,  73 

11 

56 

12 

12,52 

13 

17 

14 

10 

15 

10, 12,52 

16 

7,  26 

17 

12,  52 

18 

38 

19 

1 

20 

38 

21 

14,20 

22 

38 

23 

vbvblO,  38,  73 

24 

1 

25 

1 

26 

10 

27 

7 

28 

1,7,56 

29 

14,56 

30 

38,56 

31 

10 

32 

14,56 

33 

1,26,  38,68 

C.5.3  Recommendations  Votes 

It  was  decided  by  acclamation  that  recommendations  receiving  fewer  than  four  votes  would 
not  be  considered  further.  It  was  demonstrated  that  all  attributes  were  satisfied  by  the  recom¬ 
mendations  receiving  four  or  more  votes. 


Votes 

11 

9 

6 

5 

4 

2 


Recommendation 

9 

8 

1,2, 10, 15, 17,33 
30 

3,  4,  7,  13 

5,18,  23,  25,  26,  28,  32 
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C.6  Observations  on  Brainstorming 

The  brainstorming  technique  was  a  great  technique  to  get  the  issues  out  in  the  open  for  discussion.  How¬ 
ever,  it  was  difficult  to  '‘remove"  an  issue  once  it  was  listed.  Even  if  several  people  disagreed  with  an  issue, 
it  remained  on  the  list  and  was  voted  on.  Voting  weeded  out  most  of  the  nonessential  issues,  but  there 
should  have  been  time  to  argue  for  removal  of  items. 

The  participants  in  this  session  worked  very  effectively.  Within  the  first  10  minutes  of  the  session,  each 
group  member  had  some  responsibility  to  the  group  (timekeeper,  scribe,  etc.).  This  helped  to  break  down 
the  initial  group  apprehensiveness  and  allowed  the  group  to  focus  on  its  tasks.  The  brainstorming  tech¬ 
nique  also  allowed  group  members  to  participate  without  being  subject  to  rejection. 

The  topic  for  this  session  was  actually  very  broad  and  a  large  amount  of  time  was  spent  simply  listing  the 
issues.  The  session  leader,  Dr.  Royce,  commented  that  he  was  very  surprised  that  the  group  had  over 
70  attributes  from  the  initial  brainstorm  and  it  was  unusual  to  have  such  a  high  number. 
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Appendix  D  CASE  Resource  Pointers 

The  following  tables  provides  a  useful  set  of  pointers  to  a  number  of  different  sources  of  infor¬ 
mation  on  Computer-Aided  Software  Engineering  (CASE)  tools.  This  information,  while  not  all- 
inclusive,  does  exemplify  the  type  of  information  that  is  available  from  commercial  and  govern¬ 
ment  sectors. 

The  8  tables  that  follow  are: 

•  Table  D-1  U.S.  Government  CASE  Information  Sources 

•  Table  D-2  CASE  Industry-specific  Reports/Directories 

•  Table  D-3  CASE  Industry-Specific  Magazine-Based  Buyer’s  Guides 

•  Table  D-4  General  Software  Industry  Reports/Directories 

•  Table  D-5  Consulting  Groups/Conferences 

•  Table  D-6  Case  Industry  Newsletters 

•  Table  D-7  CASE  Trade  Shows 

•  Table  D-8  CASE  User’s  Groups 


CMU/SEI-91  -TR-1 4 


89 


f  '  s*V  <  1 }.  ii  i.  K.i.iS.  $ 

.. 

ns 

GSA  CASEbaaa - 

Judith  Andrews 

GSA/osorr 

5203  Leesburg  Pike 

Suite  1108 

Falls  Church,  VA  22041 

(703)  756-4500 

CASE  database  of  vendors/ 

tools  and  government  users/ 

evaluators 

STSC  CASE  Database/ 

•Toolbox  PC 

Air  Force  Software  Technology  Support  Center 

Reuel  Alder 

OO-ALC/TISAC 

Air  Force  Software  Technology  Support  Center 

Hill  AFB,  UT  84056 

AV  458-8045 

(801)777-8045 

Also  contact  tor 

Joint  Software  Support  Conference 

April-1 992 

Salt  Lake  City,  UT 

Sponsored  by  HO  USAF/SC 
and  the  Pentagon 

Syatams  Engineering  Tools 
for  Computer-Aided  Design 
of  Ultra-Reliable  Systems 

Appendix  A,  Table  A-10  CASE  Tools 

BATTELLE 

Tactical  Technology  Center 

505  King  Avenue 

Columbus,  OH 

Sponsored  by  DARPA 

Available  thru  Defense  Technical  Information  Center 

(202)274-6847 

Table  of  173  CASE  tools 

Reviews  of  Selected  System  and 

Software  Tools  for  Strategic 

Defense 

Institute  for  Defense  Analyses 

IDA  Paper  P-2177 

Alexandria,  VA 

Defense  Technical  Information  Center 

Session  Number  ADA226  982 

(703)  274-7633 

Covers  Software  through  Pictures, 
Teamwork,  TAGS,  Auto-G,  DCDS, 

RDD,  Statement,  Refine,  Design/ 

IDEF,  001,  Foresight,  Virtual  Softtware 

Factory  A  Adagen 

Evaluation  of  Existing  CASE  Tools 
for  Tactical  Embedded  System 

CECOM  Center  for  Software  Engineering 

US  Army  CECOM 

AMSEL-RD-SE-AST-SE 

Ft.  Monmouth,  NJ  07703 

(908)  532-2342 

Covers  Teamwork.  ProMod,  EPOS, 
Software  through  Pictures,  Stalemate, 
Autocode,  Model,  CCC,  Foresight, 

T  A  SuperCASE 

Software  Engineering 

TOOLS  CATALOG 

The  Aerospace  Corporation 

ATR -0089(81 1 5)- 1 

El  Segundo,  CA  90245-4691 

Covers  Anatool,  DataViews,  Design 

Aid,  Docwriter,  Excel  era  tor,  FDM, 

Nexpert  Object,  PIES,  P-NUT, 

PowerToots,  Software  Size  Estimator, 
Software  through  Pictures,  Stalemate, 
Teamwork,  TekCASE 

Table  D-l  U.S.  Government  CASE  Information  Sources 
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An  Annotated  CASE  Bibliography 

nr a 

Software  Engineering  Notes 

Dept  of  Computer  Science 

vol  15  nol 

University  of  Jyv  skyl 

‘Jan  1990  Page  79 

SeminaarinKatu  15 

SF -40100  Jyv  skyl 

FINLAND 

■ m 

POB68 

Newtonville,  MA  02160 

(617)893-9130 

Implementing  CASE:  A  Manager's  Guide 

$595 

CASE  Conaortium 

Center  for  Study  of  Data  Processing 

CASE  Studies  Annotated  Software/Systems  Bibliography 

unknown 

Washington  Univeisity 

(over  400  citations  in  20  categories) 

Campus  Box  1141 

Prince  Hall  224 

One  Brooking  Drive 

St  Louis.  MO  631 30-4899 

(314)889-4792 

CASE  Studies  Consortium  MIS  Industry  Survey 

unknown 

CASE  Consulting 

1 1830  S.W.  Kerr  Parkway 

An  Introduction  to  CASE:  The  Best  ol  CASE  OUTLOOK 

$225 

Group,  Inc. 

Suite  315 

Annual  CASE  Directory 

$195 

Lake  Oswego,  OR  97035 

The  Executive's  Guide  to  CASE 

$95 

CASE  Research 

155  108th  Ave.N.E. 

"The  Strategic  Impact  ol  CASE *  -  Volume  1  Video 

Suite  210 

"The  Strategic  Impact  ol  CASE ”  -  Volume  II  Video 

1 

Bellevue,  WA  98004 

Annual  CASE  Survey  1988 

$150 

CASE  Bulletins 

$125 

Note:  CASE  Research  recently 

CASE  in  Practice  reports 

$225 

merged  with  Ernst  8  Young 

Product  Profiles 

$225 

For  more  information  contact: 

Ernst  8  Young's  Center 

for  Information  Technology  Strategy 

(617)742-2500 

The  Second  Annual  Report  on  CASE 

$595 

German  National 

Western  US  Office 

The  CASE  Products  '90 

Free 

Research  Center 

1942  University  Avenue 

(Macintosh  HyperCard-based  Public  Domain  Database) 

For  Computer  Science 

Berkeley.  CA  94704 

available  on  Internet,  anonymous  FTP 

(GMD) 

Publication 

sumex-aim.stantord.eduVinfo-macfcard/case-product-l  1  hqx 

Ovum  Ltd 

7  Rathbone  Street 

Analysis  Techniques  for  CASE:  a  Detailed  Evaluation 

$995 

London  W1P1AF 

CASE  Analyst  Workbenches:  a  Deoiled  Evaluation 

$995 

England 

CASE:  the  Next  Steps 

$995 

Real-time  CASE:  the  Integration  Battle 

$995 

Reverse  Engineering:  Markets,  Methods  and  Tools 

$1,850 

572  East  Lambert  Rd 

Brea,  CA  92621 
(714)990-3169 

CASEbase  (a  PC-based  CASE  database) 

$495 

For  information  contact: 

Digital  Consulting,  Inc. 

204  Andover  Street 

Andover,  MA  01810 
(508)  470-3880 

1990  CASE  Evaluation  Report 

unknown 

Software  Productivity 

POB  294-MO 

CASE  Trends  Industry  Guide 

$179 

Group,  Inc. 

Shrewbury,  MA  01545-0294 
(508)  842-4500 

Table  D-2  CASE  Industry-  Specific  Reports/Directories 


CMU/SEI-91  -TR-1 4 


91 


mputer  [ 
mputerworfd 
C  User 


hange  control  meats  < 

CASE  software  products 
Vendors  pack  functionality  into  Case 


jital  Review 
jital  Raviaw 
jital  Raviaw 


21  Nov  88 
24  Jul  89 
23  Apr  90 


v5  n22 
v6  n29 
v7n16 


p61(7) 

p37(7) 

P37(5) 


CASE:  tech  toolkits  for  sokd  software. 

Diverse  CASE  offerings  deliver  solid  applications  with  speed  and  finesse 
Project  management  packages  offer  sophisticated  features 


ivarnmant  Computer  Nawa 

EE  Sottwara 

icintosh  Buyartt  Guida 


7  Aug  89 
1  May  90 
Fall  1989 


v8  nl6 
v7n3 


p56(4) 
pi  4(57) 
P72 


CASE  tools:  timely  assistance  for  PC-based  software  designers 
Tools  Fair 

Fall  1989  -  Desktop  Engineering  Directory 


■  Week 
'•  Week 
:  Week 


21  Aug  89 
21  Aug  89 
21  Aug  89 


v6n33 
V6n33 
v6  n33 


p100(1) 

p95(1) 

P98(1) 


Education  clearing  the  way  tor  implementing  CASE 
CASE  spurs  the  re-engineering  of  users’  hearts  and  minds 
CASE  brings  order  to  complex  development  efforts 


iftware  Magazine 
ittwara  Magazine 


1  Oct  90 
1  Apr  89 


vIO  n12 
v9n5 


p4 1 ( 10) 
p33(8) 


The  race  is  on  for  tools  enabled  to  IBM  repository 
The  CASE  way  of  life:  to  each  his  own  method 


Table  D-3  CASE  Industry-Specific  Magazine-Based  Buyer’s  Guides 
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Oata  Decisions,  Inc. 

Cherry  Hill,  N.J. 

Data  Decisions  software 

unknown 

DATA  Sources 

Ziff  Communications  Company 

One  Park  Avenue 

New  York,  NY  10016 

(212)  503-5398 

DATA  Sources 

$495 

Datapro 

McGraw-Hill  Info.  Sys.  Co. 

Datapro  directory  of  microcomputer  software 

$779 

Computers  &  Comm.  Info.  Group 

PC  Digest  Ratings  Report 

unknown 

1805  Underwood  t’tvd. 

Software  Digest  Ratings  Report 

unknown 

Del  ran,  NJ  08075 

Software  Digest  Macintosh  Ratings  Report 

unknown 

NT  IS 

5285  Port  Royal  Rd. 

Springfield,  VA  22161 

A  directory  of  computer  software 

unknown 

Table  D-4  General  Software  Industry  Reports/Directories 
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gital  Consulting,  Inc. 

204  Andover  Street 

Andover,  MA  01810 
(508)  470-3880 

Accelerating  Applications  Development  (Using  kAb,  6ASEI  ) 
Analyzing  User  Requirements 

Capers  Jones:  Software  Measurement  &  Estimation 

CASE:  The  Next  Generation 

Computer-Aided  Software  Engineering  Symposium 

Data  Modeling  and  CASE 

Evaluating  CASE  Tools 

IBM's  AD/Cyde 

Implementing  Software  Engineering  and  CASE 

Extended  Intelligence,  Inc. 

(Associated  with  Dr.  Carma  McClure) 

25  East  Washington  Street 

Suite  600 

Chicago,  IL  60602 
(312)  346-7090 

CASE  lor  the  1990s 

Re-Engineering,  Repositories,  Reusability 

Software  Development  Concepts 
(Associated  with  Dr.  Paul  Ward) 

424  West  End  Avenue 

Suite  11E 

New  York,  NY  10024 
(212)362-1391 

The  CASE/Real  Time  Curriculum 

Table  D-5  Consulting  Groups/Conferences 
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American  Programmer 


C/A/S/E  Outlook  Industry  Report 


CASE  Strategies 


CASE  World  News  &  Digest 


Software  Engineering 
Tools,  Techniques,  Practice 


American  Programmer 
161  West  8601  Street 
New  York,  NY  10024-3411 


CASE  Consulting  Group,  Inc. 
11 830  S.W.  Kerr  Parkway 
Suite  315 

Lake  Oswego,  OR  97035 


Cutter  information  Group 
1100  Massachusetts  Avenue 
Arlington,  MA  02174 
(617)  648-8700 


Software  Productivity  Group,  Inc. 
POB  294-MO 

Shrewbury,  MA  01545-0294 
(506)  842-4500 


Digital  Consulting,  Inc. 
204  Andover  Street 
Andover,  MA  01810 
(508)  470-3880 


Auerback  Publishers 
210  Sourth  Street 
Boston,  MA  021 1 1 
(800)  950-1216 


Table  D-6  CASE  Industry  Newsletters 
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:ASE  World 


204  Andover  Street 
Andover,  MA  01810 
(508)  470-3880 


CASExpo 

CASExpo 

Suite  1210 

5203  Leesburg  Pike 

Falls  Church,  VA  22041-3401 

(703)  284-7330 

Tri-Ada 

Daniel  A  O'Keefe  Associates,  Inc 

Conference  Management 

75  Union  Aveue 

Sudbury.  MA  01776 
(1-800-833-7751) 

CASELab  '90 

Research  &  Technology  Institute 

301  West  Fulton.  Suite  718 

Grand  Rapids,  Ml  49504 
(816)  771-6626 

Table  D-7  CASE  Trade  Shows 


S! i  U.l/f  ItU 


International  CASE  UaarlA  Group 

Computer  &  Engineering  Consultants,  Ltd. 

18620  West  Ten  Mile  Road 

Southfield,  Ml  48075-2667 

Sponsored  by  CASE  Research 

CASE  Uaar'a  Network 

Digital  Consulting,  Inc. 

204  Andover  Street 

Andover,  MA  01810 

(508)  470-3880 

Sponsored  by  Orbital  Consulting,  Inc. 

Table  D-8  CASE  User's  Groups 
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The  Challenge  of  Implementation 

When  better  mousetraps  go  unused,  most  people  wonder  why.  We  have  a  contrary  view. 
We  assume  that  many  innovations  will  not  be  used,  and  when  they  are,  we  worker  why.  Given 
the  difficulties  of  moving  along  die  technology  life  cycle,  innovations  will  often  remain  "on  the 
shelf'.  Our  curiosity  is  aroused  in  the  rare  instances  when  everything  goes  right 

Our  view  is  not  overly  pessimistic  Innovation  does  occur,  and  we  an  do  filings  to  make 
it  occur.  We  do,  however,  want  to  convey  a  sense  of  why  innovation  is  difficult  and  from  there 
to  show  how  successful  innovation  can  be  realized. 

We  will  begin  with  the  long  view,  looking  at  innovation  in  terms  of  its  entire  life-cycle. 
In  a  second  section  we  will  concentrate  on  specifics  of  what  end-users  can  do  to  facilitate  useful 
innovation,  and  follow  with  an  example  relating  the  dynamics  of  innovation  to  the  specifics  of 
software  engineering  tools.  Finally,  we  will  conclude  with  a  few  words  concerning  the 
evaluation  of  CASE  implementation  and  use. 


Views  of  the  Technology  LifeOde 

Two  models  of  technological  innovation  illustrate  different,  but  complementary  views  of 
its  difficulties.  The  first  maps  critical  events  against  both  the  stages  of  development  and  the 
parties  involved.  Figure  1  illustrates  this  view. 


Figure  Is 
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At  the  simple  level,  everything  moves  from  left  to  right  Essentially,  this  is  a  modified 
"stage  and  phase"  view  which  explains  events  as  innovations  move  through  their  life  cycle. 
There  are,  however,  two  major  deviations  from  the  traditional  stage  view: 

First,  there  are  numerous  feedback  loops  and  recursions  among  the  stages. 

Second,  there  is  no  assumption  that  development  must  begin  in  the  research  community. 

As  examples  of  these  complications,  consider  the  following  common  dynamics  in  technological 
innovation: 

Early  users  (for  instance  those  in  classic  beta  site  activity),  influence  late  stage 
development 

Use  of  an  implemented  technology  may  generate  new  needs  which  then  influence 
research. 

Many  new  technologies  are  founded  on  accepted  scientific  principles,  are  motivated  by 
market  need,  and  have  no  close  connection  with  basic  research. 

Several  important  principles  are  embedded  in  this  diagram. 

The  first  principle  is  that  the  organizations  involved  in  each  stage  tend  to  be  different. 
Research  takes  place  in  universities  and  federal  laboratories,  development  is  carried  out  by 
commercializing  or  R&D  firms,  while  the  later  stages  are  carried  out  by  end  users.  In  some  cases 
research,  development  and  adoption  may  take  place  in  the  same  firm.  In  these  situations, 
however,  the  functional  units  within  the  firm  are  highly  distinct  A  company's  Research 
division,  for  instance,  tends  to  be  far  distant  from  potential  end-using  divisions  within  the  same 
company. 

The  second  principle  is  that  important  activities  take  place  at  different  levels  of  social 
aggregation.  Consider  a  few  examples.  At  the  research  end  of  the  continuum,  individuals 
publish  articles,  while  the  "scientific  environment"  commits  to  one  or  another  paradigm.  Or 
consider  activity  at  the  implementation  stage.  Purchase  orders  -  based  on  previously  developed 
acquisitions  policies  -  exist  mostly  at  the  firm  level.  Getting  purchased  equipment  used, 
however,  takes  place  by  "product  champions",  working  at  the  individual  and  work  group  levels. 
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The  third  principle  is  that  levels  of  aggregation  -  individuals,  work  groups,  organizations, 
and  so  on  -  do  influence  each  other,  but  only  in  complex  ways.  An  illustration  from  die  world 
of  software  engineering  can  be  found  in  the  debate  over  whether  formal  systems,  because  of 
their  complexity,  can  be  made  suitable  for  real-world  settings.  The  dominant  view  is  that  such 
systems  are,  and  will  remain,  too  complex.  That  world  view  will  not  be  changed  by  any  given 
individual  opinion  or  research  study.  A  change  will  come  only  if  enough  people,  with  enough 
evidence,  holding  important  enough  positions,  change  their  fundamental  views.  The  dynamic 
of  change  is  as  much  sociological  as  scientific 

The  fourth  principle  is  that  the  rate  of  progress  along  die  life  cycle  is  protracted. 
Prototype  CASE  tools,  for  instance,  were  available  in  die  mid-1970's.  The  tools  became  generally 
available  in  die  early  to  znid-1980's,  but  their  use  is  still  limited. 

Finally,  the  model  indicates  that  understanding  technological  development  requires  a 
variety  of  levels  of  analysis,  and  that  interactions  among  those  levels  can  be  important 
Paradigm  shifts  do  not  occur  because  individuals  write  articles.  There  is,  however,  a  relationship 
between  the  articles  people  write,  and  accepted  views  of  a  scientific  or  technological  endeavor. 
Similarly,  a  company's  acquisitions  policies  are  in  important  ways  -  but  only  partially  and 
indirectly  -  related  to  the  actions  of  product  champions. 

The  above  model  conveys  a  sense  of  how  technological  innovation  may  be  understood, 
but  it  only  alludes  to  die  nature  of  relationships  among  relevant  parties,  and  to  how  die  system 
can  be  affected  by  direct  action.  There  are  leverage  points  in  die  life  cycle,  particularly  in  the 
relationship  between  technology  developers  and  end-users.  A  guide  for  identifying  that  leverage 
emerges  from  our  second  view  of  technological  development  This  view  can  be  found  in 
illustration  2. 

Figure  2:  Leverage  Points  for  Promoting  CASE 


The  process  depicted  in  the  model  begins  with  vendor  decisions  as  to  whether  a 
technology  should  be  developed  or  marketed.  Included  in  this  decision  are  factors  such  as  the 
characteristics  of  the  technology  ^question,  market  structure,  and  goals  concerning  marketing 
incremental  improvements  versus  radical  new  solutions.  A  prime  example  for  CASE  tool 
vendors  is  the  question  of  whether  a  particular  tool  will  require  domain  specific  interfaces  for 
different  users.  The  more  important  that  differentiation,  the  greater  will  be  the  cost  of 
development  and  the  cost  of  sales. 

These  vendor  deliberations  determine  whether  a  product  will  be  made  available.  Once 
available,  the  product  can  be  characterized  by  a  number  of  important  variables.  These  include 
price,  functionality,  modularity,  compatibility  with  other  products,  and  ease  of  use. 

That  unique  product  then  interacts  with  two  multi-faceted  elements  that  determine  whether 
a  technology  will  be  accepted  by  end-users.  The  first  element  is  end-users'  ability  to  use  a 
product  Determinants  of  that  ability  include  variables  such  as  the  users'  technical 
sophistication,  technology  infrastructure,  planning  capacity,  human  resources,  and  management 
capabilities. 

Consider  for  example,  a  tool  to  assist  people  in  cataloguing  and  finding  reuse 
components.  Such  a  tool  would  be  useful  only  if  an  organization  had  a  serious  commitment  to 
reuse.  Would  management  be  willing  to  encourage  reuse  by  including  its  deployment  in  the 
performance  reviews  of  developers,  or  by  establishing  a  separate  group  to  maintain  reusable 
components?  Do  an  organization's  developers  know  what  how  to  write  a  reusable  component, 
and  do  they  have  the  technical  sophistication  to  piece  a  system  together  from  such  components? 

The  second  multi-faceted  element  of  acceptance  is  the  users'  need  for  the  technology  in 
question.  Determinants  of  need  include  factors  such  as  competitive  environment,  demands  for 
quality,  and  the  developing  organizations  relations  with  its  customers.  To  continue  the  reuse 
example,  a  software  company  might  ponder  whether  its  competitive  environment  rewards  fast 
development  of  custom  software.  If  not,  the  difficulties  of  implementing  a  reuse  program  may 
not  be  worthwhile. 

Finally,  "ability  to  employ  technology",  and  "need"  combine  to  explain  two  aspects  of 
technology  acceptance  -  implementation  and  use.  The  distinction  between  implementation  and 
use  is  important  because  much  purchased  technology  is  unused  or  under-used. 

Also  included  in  our  model  are  numerous  feedback  loops.  As  examples,  user  experience  with 
an  existing  product  may  affect  vendor  decisions  about  new  products;  changing  user  needs  may 
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affect  vendor  decisions  about  pricing  or  functionality;  and  widespread  use  within  an 
organization  can  change  both  the  organization's  further  need  for  the  technology,  and  its  ability 
to  exploit  that  technology. 

We  also  believe  that  by  identifying  specific  factors  operating  at  each  transition  in  the 
model,  possibilities  for  end-user  influence  on  the  process  can  be  realized. 


End-user  Influence  on  CASE  Technology 

An  important  principle  from  the  end-user  point  of  view  is  that  proximate  impact  is  more 
powerful  than  remote  influence.  Thus,  end-users  can  better  control  their  own  implementation 
strategies  than  they  can  influence  decisions  made  by  technology  vendors.  The  second  principle 
is  that  users  and  vendors  are  linked  in  a  system,  and  that  comprehensive  solutions  require  a 
systems  perspective.  We  will  now  describe  how  end-users  may  impact  all  aspects  of  the 

system,  with  special  emphasis  on  difficulties  posed  by  problems  related  to  an  organization's 
need  for  technology,  and  its  ability  to  use  technology. 

The  greatest  stretch  for  end  users  is  an  attempt  to  influence  activities  going  on  in  the 
research  community.  Some  privileged  users  have  enough  resources,  and  enough  influence,  to 
actually  fund  CASE  related  research,  or  to  influence  the  research  agenda  of  organizations  who 
are  doing  such  research.  In  most  cases,  however,  influence  will  be  less  direct  and  more  diluted. 
One  possibility  that  comes  to  mind  is  membership  in  various  consortia  such  as  MCC2,  CAM-I3, 
OSF4,  and  CASE  users'  groups.  Another  possibility  is  gaining  membership  to  research  based 
organizations  that  actively  seek  advice  from  the  outside.  Organizational  affiliate  status  at  the 
Software  Engineering  Institute,  and  participation  in  their  resident  affiliate  program  are  prime 
examples. 

Less  of  a  stretch,  but  still  not  easy,  are  attempts  to  influence  the  behavior  of  the  producers 
of  technology.  Participation  on  standards  committees  is  one  prominent  route  to  influence. 
Standards  influence  the  size  of  markets,  the  compatibility  of  diverse  technologies,  the  likelihood 
of  value  added  products  being  developed,  and  a  host  of  other  factors  which  may  sway  vendors' 
decisions  about  what  to  produce,  and  how  to  configure  what  they  produce. 


2  -  Microelectronics  and  Computer  Technology  Corporation 

3  -  Computer  Aided  Manufacturing  -  International 

4  -  Open  Software  Foundation 
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A  less  collective  tactic  is  to  serve  as  a  beta  site  for  new  products.  So  doing  will  set  up 
a  direct  and  dose  relationship  that  may  well  affect  the  shape  of  a  product  or  its  dose  cousins. 
Finally,  overlapping  memberships  in  professional  assodations  may  open  channels  of 
communication  and  influence. 

However  effective  the  above  strategies  may  be,  end  users  are  most  likely  to  have  the 
greatest  influence  on  the  transition  of  existing  products  into  their  own  organizations.  To  manage 
this  transition,  we  propose  a  perspective  which  derives  from  our  attempts  to  introduce  new 
production  technologies  into  manufacturing  settings,  an  approach  we  call  HIT  OP  -  High 
Integration  of  Technology,  Organization,  and  People. 

The  essence  of  this  approach  is  to  begin  with  initial  decisions  about  technology,  and 
dosely  follow  with  tightly  linked  considerations  of  mutual  influences  among  the  chosen 
technology,  its  organizational  context,  and  available  human  resources.  Adjustments  must  be 
made  until  the  fit  is  as  good  as  possible. 

To  manage  this  process  we  invoke  an  inter-disciplinary,  and  inter-functional 
implementation  management  team  whose  members  work  concurrently  with  each  other.  For 
CASE  tool  implementation,  team  members  might  indude: 

members  of  application  development  teams, 

development  managers  at  the  group  and  project  level, 

a  representative  from  human  resources  who  can  speak  to  issues  of  training,  reward 
systems  and  hiring  policies,  and 

corporate  experts  who  can  represent  the  business  case  for  what  new  tools  should 
accomplish 

The  goal  of  the  team  is  to  develop  a  process  for  CASE  tool  implementation  that  will 
overcome  the  very  good  reasons  not  to  use  such  tools.  After  all,  CASE  tool  introduction  will: 

require  changes  in  organizational  and  management  procedures, 

disrupt  current  operations,  and 

alter  people's  comfortable  working  style. 
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Consider,  for  example,  the  extent  of  changes  that  may  be  required  by  CASE  tool  use.  Such  tools 
often  require  the  use  of  particular  methodologies.  While  tool  use  may  not  require  profound 
changes  in  how  people  develop  applications,  new  methods  are  very  likely  to  require  such 
changes.  What  would  happen,  for  instance,  if  a  tool  relied  on  object  oriented  design,  and  the 
adopting  organization  did  not  employ  such  design  methodologies?  Further,  organizational 
culture  might  exacerbate  the  difficulties  of  needed  change.  Imposing  a  particular  method  in  a 
"cowboy  culture”  could  prove  exceedingly  problematical. 

In  developing  a  CASE  implementation,  interactions  among  the  HITOP  elements  must  be 
specifically  addressed.  Consider  some  of  the  elements  of  each  that  must  come  together  for  a 
CASE  implementation  to  be  successful. 

Technology  includes 

network  infrastructure 
hardware  platforms,  and 

development  life-cycles  in  which  tools  are  embedded. 

Organization  includes 

coordination  among  developing  units, 
accepted  mechanisms  to  track  progress  and  quality, 
implementation  schedules  and  timing, 
acquisitions  policies  and  procedures, 

monitoring  of  tool  use  to  detect  problems  and  correct  difficulties,  and 
training,  incentive,  and  hiring  policies  to  support  tool  use. 

Human  resources  include 

skills  of  workforce, 
workload,  and 

availability  of  qualified  new  hires. 

We  do  not  mean  to  imply  that  all  considerations  are  of  equal  importance  -  they  most 
certainly  are  not  But  important  considerations  are  ignored  at  one's  peril.  CASE  implementation 
teams  must  make  systematic  efforts  at  identifying  and  considering  all  important  factors  in  their 
particular  settings.  CASE  technology  is  not  "self  implementing".  Making  the  technology  work 
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involves  resolving  the  conflicts  that  inevitably  arise  because  of  the  work  and  organizational 
changes  that  are  inherent  in  using  CASE  tools. 

We  also  believe  that  the  effort  put  into  managing  the  introduction  of  CASE  must  match 
the  scale  of  the  implementation.  It  is  one  thing  to  test  CASE  feasibility  in  a  few  isolated  work 
groups.  Organization  or  department-wide  implementation  is  quite  something  else.  The  critical 
point  is  that  wide-spread  use  of  CASE  can  be  very  costly  in  terms  of  time,  effort,  and  money. 
When  such  implementation  occurs,  appropriate  care  must  be  taken  to  design,  manage  and  assess 
implementation  schemes. 


Illustrative  Examples 

At  this  point  it  may  be  useful  to  trace  out  some  detailed  examples  of  how  the  three 
elements  of  HITOP  interact  in  CASE  tool  implementation. 

Example  #1 

As  an  organizational  setting,  imagine  a  company  with  the  "cowboy  culture"  alluded  to 
above.  Let  us  further  assume  that  this  organization  is  staffed  with  highly  competent  developers, 
and  has  both  the  resources  and  commitment  to  do  training.  Three  types  of  CASE  tools  are  being 
considered. 

1-  a  full  fledged  CASE  environment, 

2-  use  of  an  object  oriented  language  (such  as  C++),  and 

3-  a  good  compiler  and  debugger  system. 

Notice  that  these  choices  have  been  listed  in  descending  order  of  the  amount  of  change 
that  each  will  entail.  The  full  fledged  CASE  environment  will  require  systematic  use  of 
particular  methodologies.  The  object  oriented  language  will  require  training  and  a  "mind  set" 
change,  but  it  will  not  necessarily  require  a  total  method  change.  Use  of  the  compiler/ debugger 
system  will  involve  only  slight  changes  in  what  people  are  used  to  doing. 

Let  us  now  overlay  these  technologically  driven  requirements  with  organizational  and 
human  resource  considerations.  Organizational  concerns  mitigate  against  the  full  environment  - 
the  change  would  be  too  drastic.  If  such  in  environment  were  a  desirable  goal,  it  should  begin 
with  a  slow  phase-in  of  a  methodology,  or  at  least  a  set  of  standard  operating  procedures.  Use 
of  tools  which  might  force  a  quick  changeover  should  come  later.  The  quality  of  staff  however. 
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and  the  availability  of  training  resources,  make  it  possible  to  choose  either  the  C++  option,  the 
compiler/debugger  option,  or  both.  The  point  is  that  making  an  informed  choice  requires 
inspection  of  all  three  of  HITOP's  elements  -  technology,  organization,  and  people. 


Example  #2 

Consider  die  technical,  organizational  and  human  resource  issues  which  may  determine 
the  fate  of  any  CASE  implementation  that  requires  a  common  data  dictionary.  A  major 
technological  concern  is  the  size  and  complexity  of  legacy  systems  intended  for  retrofit  with 
common  data  elements.  As  the  size  of  those  systems  increases,  so  too  will  the  difficulty  of 
effecting  necessary  changes. 

A  second  technological  issue  is  the  size  of  new  applications  to  be  developed.  Again,  size 
and  complexity  increase  implementation  effort,  and  thus  decrease  the  chances  of  successful 
implementation.  Using  common  terms  within  a  single  development  group  is  relatively  simple. 
Including  a  few  groups  is  difficult  but  possible.  Enterprise-wide  commonality  would  require  a 
major  commitment  of  time  and  resources. 

A  further  complicating  factor  in  coordinating  diverse  teams  is  work  culture.  Imagine  two 
teams,  one  whose  members  are  committed  to  a  uniform  approach  to  software  design  and 
internal  peer  review,  and  one  whose  members  insist  on  expressing  their  individual  style.  A 
company  filled  with  the  first  type  of  development  team  will  have  an  easier  time  implementing 
common  dictionaries  than  will  a  company  populated  by  the  latter. 

Because  implementing  common  data  dictionaries  is  difficult,  the  effort  should  only  be 
made  if  it  is  judged  feasible  and  necessary  from  an  organizational  point  of  view.  Is  there  enough 
high  level  management  control  to  make  the  change  work?  Consider  how  such  management 
control  may  change  with  the  organizational  structure  of  an  Information  Systems  Department 
In  some  cases  those  structures  are  highly  centralized,  with  all  developers  ultimately  reporting 
to  a  single  Vice  President  of  Information  Systems.  In  other  cases,  developers  are  highly 
decentralized,  with  different  groups  reporting  to  the  heads  of  various  business  units  or  divisions. 
The  former  case  makes  it  much  easier  to  influence  an  organizations'  overall  "application 
development  climate"  than  the  latter. 

Another  organizational  concern  is  the  need  to  maintain  complex  and  large  data 
dictionaries.  Depending  on  size  and  complexity,  a  dedicated  maintenance  group  may  be 
required.  Many  organizational  factors,  however,  bear  on  whether  such  groups  can  be  established. 
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Finally,  the  human  resource  dynamics  must  be  considered.  Common  data  dictionaries 
are  part  of  development  systems  which  open  people's  work  to  scrutiny  by  others.  How  will  an 
organization's  applications  developers  respond  to  such  scrutiny,  and  what  will  be  their  reaction 
to  any  system  that  increases  that  level  of  openness?  Further,  the  potential  sensitivity  of  these 
new  systems  will  interact  with  the  existence  of  innovation  champions  among  the  development 
groups  affected.  If  enough  respected  technical  experts  support  tool  use,  successful 
implementation  becomes  more  likely.  If  that  support  is  lacking,  management  desire  for  tool 

use  may  be  of  little  avail. 


Evaluation 

Because  CASE  use  can  have  such  profound  consequences  for  an  applications  development 
environment,  implementation  efforts  should  be  evaluated  in  order  to  provide: 

guidance  for  improving  implementation, 

direction  for  better  exploiting  available  CASE  technology, 

information  for  follow-on  efforts,  and 

a  sense  of  whether  (and  how)  future  CASE  implementations  can  be  justified. 

Because  evaluation  methodology  and  measurement  of  CASE'S  impact  are  much  discussed 
elsewhere,  we  will  avoid  a  discourse  on  these  topics  here.  What  is  missing  from  previous 
discussions  we  feel,  is  an  overall  intellectual  structure  that  can  direct  powerful  and  useful 
evaluation.  Here  we  hope  to  convey  our  view  of  that  structure. 

Our  approach  is  adapted  from  much  work  we  have  done  studying  the  impact  of  office 
automation,  and  is  presented  schematically  in  figure  3. 
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Figure  3:  CASE  Evaluation  Scheme 


This  model  contains  several  desirable  features.  It  begins  with  die  most  immediate  locus  of  CASE 
impact  -  activities  of  the  work  groups  that  employ  die  tool  Change  at  this  level  is  likely  to  be 
the  most  easily  observable  of  all  CASE  impact  Further,  understanding  local  impact  provides 
a  sense  of  what  more  diffuse  impact  may  be.  Starting  with  work  groups  also  forces  assessors 
to  consider  the  pace  of  implementation,  and  to  coordinate  data  collection  with  that  schedule. 

The  model  implies  that  CASE  technology  can  have  two  qualitatively  different 
consequences  -  it  can  affect  foe  work  that  is  done,  and  it  can  affect  potential  to  do  new  kinds  of 
work.  We  believe  this  is  important  because  much  information  technology  cannot  be  justified  if 
its  sole  consequence  is  to  allow  people  to  do  traditional  work  faster. 

A  third  characteristic  of  die  model  is  that  it  forces  attention  on  die  diffusion  of  impact 
to  other  parts  of  the  organization.  These  second  order  effects  might  be  extremely  important 
As  a  simple  example,  a  small  productivity  increase  in  many  development  groups  may  translate 
into  a  [announced  improvement  in  an  organization's  ability  to  respond  to  its  markets. 


Finally,  the  model  has  a  time  component  The  nature  of  impact  changes  from 
implementation  through  routinization,  and  assessment  must  sample  that  impact  throughout  that 


time 
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Summary 


The  four  important  elements  of  this  presentation  can  be  characterized  with  the  following 
statements. 

CASE  implementation  can  be  planned,  managed,  and  evaluated. 

Efforts  to  promote  the  vise  of  CASE  must  be  seen  in  terms  of  the  entire  technology  life 
cycle. 

Strategies  within  that  life  cycle  have  varying  time  horizons  for  success,  and  different 
requirements  for  collective  versus  individual  action.  In  some  cases  organizations  can 
solve  problems  for  themselves.  For  others,  inter-organizational  cooperation  is  required. 

Within  any  single  organization,  CASE  implementation  hinges  on  a  set  of  highly 
dependent  interactions  among  the  HITOP  elements  -  technology,  organization,  and 
people. 

If  we  have  sharpened  your  sensitivity  to  these  issues,  we  consider  this  presentation  a  success. 
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